Showing posts with label programming. Show all posts
Showing posts with label programming. Show all posts

Saturday, February 11, 2017

MinGW? MinGW-w64? Msys? MSYS2?

I've got a more serious blog post in the pipelines. However, right now, I just want to take a moment and complain about a mess I came across.

So, it's been a while since I have last programmed in C or C++. In fact, I have never done any real C programming and it's been over half a decade since I was serious about a C++ project. I have recently done some Arduino work, but there you don't really have to worry about the compiler yourself, so it's not relevant here. And because the compiler is what I am talking about here, so C++ and C can be thrown on the same pile, as I use the GNU Compiler Collection (gcc) for both.

Man, the gcc for windows situation is a mess...

So, there has always been MinGW and Cygwin. Cygwin is a whole POSIX emulation stack. Programs had to be compiled specifically for running in the Cygwin environment, but it was easy to do this for any linux program. Such programs would always need at least the Cygwin compatibility layer dll to run. Many people also just use Cygwin for a linux-like environment (since the GNU tools provide what many people consider "linux-likeness") on Windows without using the compiler. I've always used some version of msys for this, but I'll get to what that is in a moment.

The other option was MinGW. Rather than a full compatibility layer, it just aims to provide a compiler that can compile things natively for Windows. You will need to talk to the Windows APIs just like you would when using a different c----ompiler like Visual C++. It's just a way to get gcc to compile for Windows.

However, MinGW was married to MSYS. MSYS was forked from Cygwin at some point, but it did away with its compatibility layer. Instead, it used MinGW to compile some of the core GNU utils for native windows. This also gives you sort of a linux-like system on Windows. This was necessary to run mingw and meant that msys was a part of the mingw project. However, you could also use mingw to cross-compile from linux to windows, in which case you didn't need msys.

Unfortunately, mingw only supported 32 bit applications. When I say around the time when this started being an issue, I mean during the days of Windows XP x64 and Windows Vista and 7, which had had 32 bit and 64 bit versions which were both used (yes, a lot has changed since then). So around that time, there was a company that developed a mingw version for 64 bit application in house. At some point, it donated this code to open source and it was tried to merge it with the mingw project. However, this project suspected there were some licensing issues and a rift occurred. A second project started, called mingw-w64. It also had its own msys version (I think) and if I remember correctly it could actually compile for 32 bit and 64 bit applications.

During this time, mingw had a bit of an installer problem. The person who had been maintaining the installer left the project and basically nobody wanted to work with the same installer building tool. This led to the installer version they provided to be horribly out of date. You had to mess around with packages to get a more recent version. They were rather hostile to help offered by volunteers from outside the project, demanding that such help would be maintained by the same person indefinitely. There was some work on a new system inspired by the apt-get interface, but there was no temporary solution in the mean time. This system got done eventually, but by then the project had suffered greatly already.

Enter git. Git is not a compiler. However, it relies on GNU tools to do its job, so it needed some of them to be able to run on Windows. So, they created their own version of msys (msysgit) which makes them relevant to this story. At some point I switched from mingw's msys to msysgit for my "proper command line" needs and since then I haven't really kept up with the mingw project.

That is, until now. I want to make a utility that uses I2C on linux and my best bet seems to be C. So, I went to look for a compiler. What I really need is a cross-compiler from Windows to ARM linux, or perhaps an ARM compiler on the device itself or maybe even a cross-compiler from x64 linux to ARM linux to run from a (virtual or other) linux installation, but I ended up looking at mingw first. I had a very old version installed as part of the haskell project (oh joy!) and a slightly more recent version from my C++ development days. So, I started looking into the mingw situation.

The mingw project seems to have bled to death. Their site is still online, but nothing seems to have happened for them in over three years. In a way, this is logical. They were already struggling in those days and today you don't really have to bother with 32 bit applications anymore as 64 bit is commonplace enough. mingw-w64 is still alive and kicking and it seams to be the way to go. However, there's also msys2.

The project page describes them as a rewrite of msys and they mention the reason for their existence is the fact that the original msys wasn't able to keep up with Cygwin. However, what I think is one of their main accomplishments is that they divorced from mingw. Don't get me wrong, they are still seeing each other, just not living together anymore. The tools are still built with a mingw version (I think the w64 version) and it is still an important way to run mingw, providing support for both (the outdated) mingw and mingw-w64 out of the box. However, they are just not the same project anymore, so the coupling is not as tight anymore (i.e. they are not wearing rings and they are allowed to see other people).

The new msys2 also does away with the apt-get inspired installer in favor of a new port of Arch's package manager, pacman. Oh, and they apparently don't play well with msysgit or the original msys. Things never get simple, do they.

Confused yet? I definitely am!

Edit: It seems there still was an important bit I missed. The more recent version of git for windows (incidentally, called Git for Windows rather than msysgit as the older versions were called) don't actually use their own msysgit anymore. Instead, they are already packaging msys2, which means that I have already been using it for quite some time...

Friday, November 25, 2011

Just a single System

Today I am writing about a thing that - as a programmer - I feel I should keep reminding myself of. Basically, that is that this is just a single system.

Writing this was inspired by a comment on a flash game I saw earlier today. The commenter was saying how the game didn't work for him, and then said that as a programmer, he knew that something serious was up and he continued to say how there was something wrong with the memory management.

Now, don't get me wrong, I program myself as well and I know how the line of thought goes all too well. However, I do feel there was something wrong with it. Namely, the commenter was sitting behind a single system (or computer, I just like the word system more in this context) and from there making comments about the entire thing. However, every system (computer) is different and the programmer could not ever have tested every single system out there.

I'm not saying there was or wasn't anything wrong with that game, but I do want to remind myself that "This is just a single system" and thus remind me that even if it doesn't work here, it might work elsewhere.

This should also be applied the other way around. When you make something, don't just run it on one computer and assume it is going to do the exact same thing everywhere. Every system is different and this is only a single system. Try it on a few more systems (try to get other people to try it as well, they often have systems that differ from yours than your desktop and laptop differ) and never be surprised if it still does something else on another system entirely.

Alright, that's all I wanted to say.

Saturday, March 26, 2011

Caveman Debugging

I recently heard about this new term: caveman debugging. It's basically where you make a program that you think might have a problem diagnose itself while it is running. Here and there you make it output useful information that might lead you to understand what is wrong - and what you can do about that.

It's a rather common thing and I do use it from time to time. I mean, it's nice and all to have a debugger, but sometimes it just works better to do it the old-fashioned way. Or maybe you just happen to be working in an environment with no debugger. Or just not a good one. Well, no matter what your reason is this time, you might well be wanting to use this technique.

And as a matter of fact, I had been looking for a name for it for a while now. How else can I refer to it clearly. Some call it printf-debugging, after one of the traditional functions used for this purpose (the printf function from C formats text and outputs it to the command line), but it's a little unimaginative. And it just doesn't fit all languages.

This term I read about, caveman debugging, has none of these problems. It really does capture the technique, but at the same time it doesn't really look down on it either. At least, not in my eyes. I mean, the word caveman sounds like strong and powerful, yet crude. Well, that's exactly what it is, so no complaining here. It also sounds like it's old, and that's what it is - it is the first type of debugging that was around - however, it does not sound like "superseded" and it is not. It's still a useful technique and should not be shunned. Well, that's why I like the name. However, the term has its own problem: people don't know it and may not guess what you mean.

So I propose a solution to that. Just use it. All of you. Write about it. (I did... uhm, am doing?) Tell each person who wonders what it is what it is. Just use it. From this moment on, it's a term in my book. And that means it's now my responsibility to spread the word.

Sunday, October 25, 2009

My hat goes off to javascript

I just started loading my streaming TNG episode, intending to watch it immediately, but then I thought I could better let it load for a while, while I gave private static some more thought. (Yes, last time I wrote about star trek I was at the first episode of DS9 and now I am halfway TNG. I tend to go through series at a reasonable pace - there was some time of not watching any Start Trek between watching DS9 and TNG.) Well... let's just say Javascript is powerful, really believe me! Now!
Oh man, the solution is so simple yet so good. All I did was declare an anonymous function that encapsulates both our class definition and our static functions and call that function right away. This requires a little change in syntax to make the class available outside that function, but that truly is a piece of cake. Once that is done, our private static variables can live in this new class.

It truly is amazing how powerful javascript is.

Jasoop Redesign

I have been typing for the documentation of Jasoop - which is what I called my style of javascript oop I talked about two days ago (technically yesterday, but not in reality).

And now I have already decided that I am going to change it all already. Here's the story.

I had thought of a way to create static functions, however, I had not realized that it would fail if the function was later redefined. Of course, this does not really matter for functions, but it did mean that I could not use the same technique for static variables. So I was once again posed the same question: how to design static in Jasoop.
I did come up with an answer: if each static property would be an object with one property (say static) I could write some code to make sure these variables were static, while keeping the syntax rather clean. Alright you would now have to type "varName.static", but that's hardly a loss. Then it hit me, if I reversed the syntax there, the code to make the variable static would be (ironically) static, rather than depend on the static variables - and I would get a nicer syntax to boot. Say it yourself: "static.varName". Isn't that much better?
My next issue was deciding whether to use the same syntax for functions or not (I mauled this all over in my head while cooking my dinner). My first impulse was not to do so, because I thought not having to write that static there would just feel much more natural. In the end, the uniformity for variables and functions did win - partly due to an argument that is really nonsense, but I only realize that while writing this. Oh, and don't worry, currently I have more than enough reason to keep it the way it is. The door was now ajar.
Next I thought of a way to create protected variables. I did think of a way (giving the class a return value if it was not called with the new operator), but that did leave me with two challenges: how to differentiate them from private variables and how to pass them through a single return value. Both questions had a single answer, I could simply use the syntax I just made up for static variables. "protected.varName" makes sense, right? Suddenly the door was swinging wide open.
And then opportunity presented itself. I could get rid of all those differences between the variables with different access levels, while getting rid of that ugly _this variable I had to introduce. Man, it cleaned up the syntax, it sure did. I was standing in front of an open door and the other side was much more beautiful than this one - needless to say I went through.

So now, inside the class we have "public.publicVar", "protected.protectedVar", "private.privateVar" and "static.staticVar". One little thing to note is that all static variables are public, but as of yet I do not see any way I can change that (unless static functions are defined outside the "class definition" they can only be accessed once the first object of the class has been created, and outside the class definition you cannot reach protected or private variables).

From the outside you can reach "object.static.varName" and public variables in some way, but I am not sure yet whether that will be "object.varName" or "object.public.varName". Perhaps it will make itself clear once I have found a way to make static variables with different access levels.

Anyway, Jasoop is coming to life and I am pretty sure the result will be nice and it will probably even include features not yet seen in javascript (protected variables, to name one thing).

Saturday, October 24, 2009

Javascript OOP

Go ahead, try googling "javascript oop". Or you you can just take it from me: you'll get a thousand ways to do object oriented programming in javascript.

Don't get me wrong, javascript a very powerful language. And I really mean very powerful. Most people working with it, though do not know its full power. For example, javascript lets you write curried functions - the syntax will be strange, but you will have curried functions, meaning you can actually go and use javascript as a functional programming language (oh, it will look horrible, but the point is that you can).
As I said, there are a lot of ways to do object oriented programming in javascript, and it appears there are few people who use the exact same way. There is a way that s default in javascript, but it has its limitations, which - as powerful as javascript is - you can work around. I picked up a style in this that turns out not too be all that common, used some more common elements in it and even added a little that is completely my own.

So that is why I decided that I am going to document this stye of object oriented programming and all its powers. For example, the model supports private data and functions, has its own (but really solid) way to define inheritance. I will document not only how to do something, but also why it is done in this way and not in some other way.
First and foremost, this will be a reference for me, so I can write consistent OOP code in javascript and so I can use powerful features - such as static functions - without first having to dig through old work to see how I did that again. However, I will make it available for others to use, as it can be a useful guide how to achieve some standard OOP features in javascript - and one might even consider using the style as a whole in order to be consistent in one's own work while having a number of powerful features at your disposal.
I do not know how I will exactly provide this documentation, right now I am just typing out the text that documents it. However, I will get back to you on that point.

Saturday, July 25, 2009

T_PAAMAYIM_NEKUDOTAYIM

I just received a brilliant error from php:

Parse error: syntax error, unexpected T_PAAMAYIM_NEKUDOTAYIM in /home/a5400048/public_html/Compiler.php on line 551.

I truly wasn't expecting a paamayim nekudotayim either. Further inspection showed it actually just meant "COLON". Php....


What I had done was typed "$class::const", while I actually just meant "class::const". It's that they told me where to look, because that error message is as descriptive as "Error: don't feel like continueing on some statement."

Monday, January 28, 2008

Reinventing The Wheel? (To Run Myself Over)

I have been working on a templating system for quite some time now. It's one of the reasons I have not been posting. Shame on me for that, by the way. Anyway, there are probably people who are reading this and now wonder what a templating system is. Well, it's definition can differ slightly, but in this case it's a system that separates the layout from the programming logic completely.

Take for example the syntax of my templating system... anything normally typed is html and is not touched by the engine at all (okey, it's touched, but left in tact completely). Anything between <: :="" and=""> is handled by the templating system, however. Any value between the two script-delimiters (that's what they are called) will be printed to the output. So if the programming logic of a page gives the page access to a 'username' I can write "Hello <:username:>" to have it say hello Jasper to me and fill it with another name.
Besides printing values the scripts can be used to call functions, I planned two functions so far, include("page.html") and nameForCounter(varName), which can execute certain tasks. Include will insert a certain file in that location, and nameForCounter will assign a variable name to the counter of the topmost for or foreach loop (which I will explain more on later), giving you a handle to refer to it in the rest of your template.
The third thing a script can do is define a control structure. Planned of these are if, else, (possibly elseif as well), for, foreach and end ... . These work on script and plain text alike, if (statement) only considers the following content if statement is true, otherwise it will simply ignore it. An if anything that occurs before the next end if or else. Likewise else only considers the content if the last if evaluated to false - and it also ends at end if. for (value1 ++>/--> value2) will repeat the content enclosed by it and end for - starting at value1, increasing (++>) or decreasing (-->) it until value2 is reached. foreach (variableName in array). Array should be one of these variables supplied by the programming logic, but it has to be an array (surprise, surprise) then we will repeat the content (ended by end foreach, you guessed it) for each element the array has, the element always being accessible through variableName.
Multiple actions can be done in one script, in such a case they must be seperated by semicolons (;).
There is another kind of delimiter the engine recognises, <:- -:="" and="">. Anything between those two is regarded as a comment and will be removed from the document. Comments can be inside and outside script tags.


So that's what my engine is supposed to do - what does it have to do with reinventing the wheel?
(warning: technical terms - unexplained - ahead)

Now, while my syntax is different, there are other templating systems around already. None of them what I wanted though, simply take your template at real time and turn it in the website you want the users to see. I discovered this is for a reason, when making my own system. Because this costs way too much time and thus is very processor intensive. So what's the alternative? I looked into the source of the most notable templating engines, Smarty (it's open source as well, really). It simply compiles the userfriendly template to a (normally) unseen php script, which runs a lot faster, the first time a page is requested since it has been modified. I decided I would have to use a similar system to come closest to my wishes. Also I learned the trick of looking at the last time modified attribute of a file to see if it needs to be recompiled. However, when looking through Smarty's source code, it made me wonder what this new choices leave as reasons to actually make my own templating system.

It took me a while to figure out if I wanted to continue development of my engine, but I decided I would. Firstly, this script is mine, so other people may use it, but I can tweak it to my needs and make it the way I want to behave. Secondly, the syntax of my system is "better" (read as: I like it more). Thirdly, I will provide some functionality that Smarty does not provide. For now, this functionality would be: reading templates from a database and writing compiled files to a database. So yes, I will make my own system, and yes I have my reasons for it. Just drop me a line if you would be interested in using my system as well.



Now, for anyone wondering about the title, try googling that phrase. Say you would not find anything (which I cannot believe, but anyway) try finding the unrelated label for this post and look in that area.

Saturday, December 15, 2007

XmlHttpRequest script 2.0

Quite a while ago, I told you about this script that I had written, which would make xmlHttpRequests for me. Now I have made a version 2.0, I ramp up all the way to the next major version umber. Why? Because there are considerable changes, including ones in syntax.
I changed the name of my function, added an argument (called args for irony's sake). Besides that the script now supports POST calls besides the regular GET calls. Also, it no longer ought to make any kind of complain when new requests are made before the first one is finished.
The script is available from here, but there are some things I really want to say. For my bandwidth (even though it won't matter much) and your security, do not include the script right from my website. Instead, download it, and put it with your website on a host and then include it using a script tag. And to make sure I won't mistake you for a "includer" do not link directly to the file, link to this post instead.
If you stick to these few rules you can use my script. A guide is to be found within the file (all commented out of course) - using the script shouldn't be too hard. Good luck with your web designing.

Changelog

  • changed the name of main function from send to request
  • added an argument to request in preparation for POST support
  • changed GET cases to work with new args argument
  • added POST support
  • made XMLHttpRequest variable local - solving problems with multiple calls after eachother
  • renamed the XMLHttpRequest variable from submitting to XHRequest
  • removed time-out as changes should have taken away any reason for it
  • deleted highPrioritySend function, as it would do nothing now
  • removed global variables busy and time_out that were related to time outs
  • made receive an inline, unnamed function inside request - allowing easier variable names
  • removed global variable next_function, as this allowed todo to be used directly (woot, no global variables anymore)

Wednesday, December 12, 2007

POST in xmlHttpRquests

Just a quick hello and dropping by a link. It's what helped me getting POST working in xmlHttpRequest.
The point is that you actually need to set some headers, to go along with that request. No long story about it for now, just a link: http://www.openjs.com/articles/ajax_xmlhttp_using_post.php

Hope it helps some of you out.

Saturday, July 7, 2007

My two scripts

So, I did not post anything anything for quite a while.
Just to let you all know I fixed the script - it turned out that IE 7 actually uses xmlHttpRequest object, like all other browsers do and I had a variable set inside the xmlHttpRequest object-specific bit, while it should have been in the general bit. Moreover this was a function variable, which made it hard to discover the mistake.
The finished script, which is just a general script to make using the xmlHttpRequest, can be found here. Instructions are found inside the document, this does dramatically increase the size of the document, but if necessary you can cut it out - just the instructions not the notices and such, under the header NOTICE you will find directions what you can and what you can not cut out.
If the need arises to update the script, (there might still be a firefox-bug and there is no support for SEND requests yet) I will update the script at that location and post here that I made the changes. Though it might seem convenient to have your script tag point to it directly, PLEASE DO NOT DO THIS. Download the file and upload it again on your website, this leaves me without bandwidth stains and leaves you with less vulnerabilities (to attacks of mine, hehe).

I made yet another script - a batch script this time. It's a really, really simple script - so if you want to be sure it is nothing malicious, open it with wordpad. If you know something about DOS-commands you will see that it's really innocent (okey, it forces a delete, but that's the whole point of the script).
Okey, I lied, you do not need the file unless you are playing on a private server, private servers change and so your cache might be in the way (if your server crew has never said anything about emptying your cache, this file might not be for you).
Put this file in your WoW folder and run it instead of WoW.exe (or Launcher.exe). This makes sure that your cache is emptied before you start WoW, every time you start WoW. (Of course you might want to change your shortcut to this file and give it back it's icon by clicking on change icon and selecting WoW.exe there).

I hope either of these two scripts can help you, and if not, too bad :P

PS. if you want to link to one (or both) of these files, please link to this post, so I do not falsely identify you as a leecher.

Saturday, June 16, 2007

From an online game to a virtual machine

So I decided to get my gears back into a project that had been abandoned for almost a year now. An online game that I started as a school project, but I didn't really finish it at the time. I had been thinking of taking it up again a long time, but did not do so until now.
The first thing I was going to do was rewrite the protocol, I needed to make it more foolproof. For making it I had simply made a chat, just to design the way the client communicates with the server. I pulled this chat out of the closet and started working on it again.
I wanted smooth transitions back in the day, so I opted for using the xmlHttpRequest method. Big mistake. It's a nice method and gives nice results (and I love knowing quite a bit about it now), but it has been taking up quite a bit of time. Okey, maybe it was not such a big mistake, but it was probably not the right choice for a school project you are supposed to spend 10 hours on (I was intending to spend more on it anyway - when hobbies and school meet there is something to be gained :P).
Anyway, I was refining my protocols, so I was dabbling with the xmHttpRequest again. Cross-browser compatibility is the worst thing with it. But in the process I found out that IE 7 actually uses the syntax every other browser uses, unlike other versions of internet explorer. One big step forward, as my new code (this time I made better use of functions and put some 'libraries' in external files and made the code so that if any file does not reach it's destination the worst thing that can happen is text that is typed not appearing on the screen) worked with IE 7 immediately after designing it for Firefox. I had left in a bit that was different for IE, but as it turned out that was only needed for IE 6 and below. Unfortunately many people still use IE 6 and thus I want my site to be IE 6-compatible. So I went and started to adjust it. My first problem was a simple mislocation of a statement (inside the non-IE bit rather than just done no matter the browser). But I wasn't out of problems yet, there was some other problem as well, which I haven't fixed yet. I needed IE 6 to see what the problem was, but I only ran IE 7, and you can not have both at the same time.
I tried MultipleIEs an application that does let you run multiples, but I wasn't able to clear the cache there and you can not ctrl-f5 a js-file (yes in FF you can, but not in IE). The big plus was that I had already installed some IE-javascript debugger (some other m$ product that dual-functioned? The debugger I tried to install last year when working on this project?). Anyway I decided to go for the one other option, making a virtual pc and running IE 6 on that (there are special images for this).
So I looked up Microsoft Virtual PC (I knew how to use it, I had dabbled with a earlier trial version before) and you know what, it was F-R-E-E. Wow, that's the second (or even third) positive thing about Microsoft in this post.
To be honest I already knew it was free, as it was told on each of the pages that told me about this workaround for running more than one version of IE... but that's where I am now, downloaded the stuff and and installed it. Now I have to get the IE dev toolbar (a friend told me about this when trying to help me with this project) to my virtual pc as well as the mysterious debugger. Let's hope it works out.