GNU Smalltalk

About a month ago, I released GNU sed version 4.2.2 and included in the release a "rant" (more of a criticism, perhaps—I'm not a native speaker) about the state of the GNU project. I made it clear that I had no philosophical disagreement with FSF; ... [More] in fact, that's likely the reason why almost no one took my post as an occasion to attack the FSF and Richard Stallman. To the few that did: guys, you clearly missed the point. I wrote that text because I want free software and the FSF to be successful. My concern is that if GNU loses, the FSF loses—even if some other piece of free software happens to win. Anyhow, these people were clearly a minority. I was surprised by the positive reactions to my post. All of the flames mostly concentrated on the virtues and sins of the C++ programming languages. I was most pleasantly surprised by the amicable reactions from fellow GNU hackers and from Stallman himself. In fact, Richard clearly understood the difference between quitting maintainership, and quitting the GNU project completely; the difference between not contributing any more code, and rescinding all links with GNU. Resigning commit access meant I'll be contributing less code to GNU, but if there are other compelling ways to help, count me in. So, here are some proposals to fellow hackers. Some of them may work out, some of them may not. It is even possible some of them are inapplicable because of U.S. law for non-profits. But I'm sure that they are welcome by the FSF, and that's already a good motivation to write them. First of all, let's talk about GNU. GNU needs updated coding standards, and coding standards are about much more than brace positioning. The GNU coding standards should summarize best practices into a free document that people can refer to; everyone, not just GNU developers. Most importantly, such an update should focus on existing best practices. If you don't like something in D-Bus or pkg-config or the Autotools, fix it upstream (and be prepared to be told you're wrong). That's how it works with free software. GNU also has a maintainer guide. The maintainer guide should document the services that GNU makes available. For example, a short guide to debbugs and the Hydra continuous integration server, both of which are used by many GNU projects. As an aside, it would be great if some of the infrastructure put in place for GNOME and other large GNU projects could be reused by all of them. Regardless of personal opinions about desktop environments, the GNOME project is clearly a successful community, and we all should learn from it! Second, let's talk about what GNU is. There are too many projects in GNU. Micromanagement is impossible at this scale, therefore nobody really tracks them. This has many problems: the signal-to-noise ratio in the list of GNU software projects is low, the different projects are not as coherent as they could be, there is little or no mentoring for new GNU maintainers, and so on. GNU should be reorganized around a few high-profile umbrella projects: for example the development environment (GCC, binutils, gdb, glibc, etc.), the build system (comprising Autotools but also gnulib), the POSIX environment, and GNOME. Everything else should either integrate itself with such a meta-project, or find another home. For example, as I mentioned in my December post, GNU Smalltalk could become a GNOME project. Third, what about the FSF? The FSF could be the home for some of these projects. GNU MediaGoblin is an obvious example, and could perhaps be a "pilot" for more projects to follow. The FSF would donate help with bureaucracy, including copyright assignment. FSF and the projects it endorses could mutually benefit in terms of branding. Similarly, organizing a donation process for FSF-endorsed projects will likely bring members to the FSF. FSF projects would be vetted quite strictly, and not judged as parts of a system---but rather, for their contribution to the advancement of software freedom. Such projects are often tied to academic work. It would be great if the FSF gave exposure to research that advances freedom. Perhaps even get access to funding from the National Science Foundation (in the U.S.) or the European Framework Programmes, and use it to hire developers for FSF projects. GNU has been producing free software for almost 30 years now, and there's no reason why it should stop. Join us now and share the software; you'll be free, hackers, and we'll do our best to make it fun! [Less]

About a month ago, I released GNU sed version 4.2.2 and included in the release a "rant" (more of a criticism, perhaps—I'm not a native speaker) about the state of the GNU project. I made it clear that I had no philosophical disagreement with FSF; ... [More] in fact, that's likely the reason why almost no one took my post as an occasion to attack the FSF and Richard Stallman. To the few that did: guys, you clearly missed the point. I wrote that text because I want free software and the FSF to successful. My concern is that if GNU loses, the FSF loses—even if some other piece of free software happens to win. Anyhow, these people were clearly a minority. I was surprised by the positive reactions to my post. All of the flames mostly concentrated on the virtues and sins of the C++ programming languages. I was most pleasantly surprised by the amicable reactions from fellow GNU hackers and from Stallman itself. In fact, Richard clearly understood the difference between quitting maintainership, and quitting the GNU project completely; the difference between not contributing any more code, and rescinding all links with GNU. Resigning commit access meant I'll be contributing less code to GNU, but if there are other compelling ways to help, count me in. So, here are some proposals to fellow hackers. Some of them may work out, some of them may not. It is even possible some of them are inapplicable because of U.S. law for non-profits. But I'm sure that they are welcome by the FSF, and that's already a good motivation to write them. First of all, let's talk about GNU. GNU needs updated coding standards, and coding standards are about much more than brace positioning. The GNU coding standards should summarize best practices into a free document that people can refer to; everyone, not just GNU developers. Most importantly, such an update should focus on existing best practices. If you don't like something in D-Bus or pkg-config or the Autotools, fix it upstream (and be prepared to be told you're wrong). That's how it works with free software. GNU also has a maintainer guide. The maintainer guide should document the services that GNU makes available. For example, a short guide to debbugs and the Hydra continuous integration server, both of which are used by many GNU projects. As an aside, it would be great if some of the infrastructure put in place for GNOME and other large GNU projects could be reused by all of them. Regardless of personal opinions about desktop environments, the GNOME project is clearly a successful community, and we all should learn from it! Second, let's talk about what is GNU. There are too many projects in GNU. Micromanagement is impossible at this scale, therefore nobody really tracks them. This has many problems: the signal-to-noise ratio in the list of GNU software projects is low, the different projects are not as coherent as they could be, there is little or no mentoring for new GNU maintainers, and so on. GNU should be reorganized around a few high-profile umbrella projects: for example the development environment (GCC, binutils, gdb, glibc, etc.), the build system (comprising Autotools but also gnulib), the POSIX environment, and GNOME. Everything else should either integrate itself with such a meta-project, or find another home. For example, as I mentioned in my December post, GNU Smalltalk could become a GNOME project. Third, what about the FSF? The FSF could be the home for some of these projects. GNU MediaGoblin is an obvious example, and could perhaps be a "pilot" for more projects to follow. The FSF would donate help with bureaucracy, including copyright assignment. FSF and the projects it endorses could mutually benefit in terms of branding. Similarly, organizing a donation process for FSF-endorsed projects will likely bring members to the FSF. FSF projects would be vetted quite strictly, and not judged as parts of a system---but rather, for their contribution to the advancement of software freedom. Such projects are often tied to academic work. It would be great if the FSF gave exposure to free software research. Perhaps even get access to funding from the National Science Foundation (in the U.S.) or the European Framework Programmes, and use it to hire developers for FSF projects. GNU has been producing free software for almost 30 years old now, and there's no reason why it should stop. Join us now and share the software; you'll be free, hackers, and we'll do our best to make it fun! [Less]

About a month ago, I released GNU sed version 4.2.2 and included in the release a "rant" (more of a criticism, perhaps—I'm not a native speaker) about the state of the GNU project. I made it clear that I had no philosophical disagreement with FSF; ... [More] in fact, that's likely the reason why almost no one took my post as an occasion to attack the FSF and Richard Stallman. To the few that did: guys, you clearly missed the point. I wrote that text because I want free software and the FSF to be successful. My concern is that if GNU loses, the FSF loses—even if some other piece of free software happens to win. Anyhow, these people were clearly a minority. I was surprised by the positive reactions to my post. All of the flames mostly concentrated on the virtues and sins of the C++ programming languages. I was most pleasantly surprised by the amicable reactions from fellow GNU hackers and from Stallman himself. In fact, Richard clearly understood the difference between quitting maintainership, and quitting the GNU project completely; the difference between not contributing any more code, and rescinding all links with GNU. Resigning commit access meant I'll be contributing less code to GNU, but if there are other compelling ways to help, count me in. So, here are some proposals to fellow hackers. Some of them may work out, some of them may not. It is even possible some of them are inapplicable because of U.S. law for non-profits. But I'm sure that they are welcome by the FSF, and that's already a good motivation to write them. First of all, let's talk about GNU. GNU needs updated coding standards, and coding standards are about much more than brace positioning. The GNU coding standards should summarize best practices into a free document that people can refer to; everyone, not just GNU developers. Most importantly, such an update should focus on existing best practices. If you don't like something in D-Bus or pkg-config or the Autotools, fix it upstream (and be prepared to be told you're wrong). That's how it works with free software. GNU also has a maintainer guide. The maintainer guide should document the services that GNU makes available. For example, a short guide to debbugs and the Hydra continuous integration server, both of which are used by many GNU projects. As an aside, it would be great if some of the infrastructure put in place for GNOME and other large GNU projects could be reused by all of them. Regardless of personal opinions about desktop environments, the GNOME project is clearly a successful community, and we all should learn from it! Second, let's talk about what GNU is. There are too many projects in GNU. Micromanagement is impossible at this scale, therefore nobody really tracks them. This has many problems: the signal-to-noise ratio in the list of GNU software projects is low, the different projects are not as coherent as they could be, there is little or no mentoring for new GNU maintainers, and so on. GNU should be reorganized around a few high-profile umbrella projects: for example the development environment (GCC, binutils, gdb, glibc, etc.), the build system (comprising Autotools but also gnulib), the POSIX environment, and GNOME. Everything else should either integrate itself with such a meta-project, or find another home. For example, as I mentioned in my December post, GNU Smalltalk could become a GNOME project. Third, what about the FSF? The FSF could be the home for some of these projects. GNU MediaGoblin is an obvious example, and could perhaps be a "pilot" for more projects to follow. The FSF would donate help with bureaucracy, including copyright assignment. FSF and the projects it endorses could mutually benefit in terms of branding. Similarly, organizing a donation process for FSF-endorsed projects will likely bring members to the FSF. FSF projects would be vetted quite strictly, and not judged as parts of a system---but rather, for their contribution to the advancement of software freedom. Such projects are often tied to academic work. It would be great if the FSF gave exposure to research that advances freedom. Perhaps even get access to funding from the National Science Foundation (in the U.S.) or the European Framework Programmes, and use it to hire developers for FSF projects. GNU has been producing free software for almost 30 years now, and there's no reason why it should stop. Join us now and share the software; you'll be free, hackers, and we'll do our best to make it fun! [Less]

Once up on a time I was sitting in a cold hall at the Barcelona exhibition ground, a power outage has taken down several DVB-H platforms (racks consisting of servers, streamers, RF equipment...) and once power was restored red LEDs were blinking ... [More] , systems not coming up automatically, hordes of engineers trying to boot the right kernel, trying to remember the multicast routes they had typed in by hand, chaos, hectic. It was interesting to witness that as we could lay back, continue with our work, as our platform was configured to come up automatically and it did. One has to assume that stuff breaks, software, disk, RAM, CPU, power supply, anything. The only answer to that is be prepared, build your software to deal with failure (or nicely try to restart), make sure all systems start automatically, have backups, have a plan. For my GSM (telephony) in Smalltalk components I didn't do that yet, mostly because my code was not very mature, I was still building up the trust relationship and so my deployment consisted of manually running GNU screen, then GNU Smalltalk, manually loading my code, starting things up. It was about time to correct that. The tool of choice is the gst-remote application, it will run a GNU Smalltalk image, it can daemonize and it will listen for input from other systems. While moving to this deployment my fellow Smalltalkers were kind enough to fix some bugs on the way. There was an issue of gst-remote exiting when saving an image, the Delay class not functioning properly on resume, the wrong FileDescriptors being closed on image resumption. It is very nice to get help that fast! My deployment now consists of building GNU Smalltalk packages, having a Smalltalk script to load the package and call start method of that package followed by taking a snapshot and exiting. I can then resume the image and if the software is prepared to deal with image resumption it will work. Eval [ | name image | name := Smalltalk arguments first. image := Smalltalk arguments second. (PackageLoader packageAt: name) fileIn; start. ObjectMemory snapshot: image; quit. ] [Less]

Once up on a time I was sitting in a cold hall at the Barcelona exhibition ground, a power outage has taken down several DVB-H platforms (racks consisting of servers, streamers, RF equipment...) and once power was restored red LEDs were blinking ... [More] , systems not coming up automatically, hordes of engineers trying to boot the right kernel, trying to remember the multicast routes they had typed in by hand, chaos, hectic. It was interesting to witness that as we could lay back, continue with our work, as our platform was configured to come up automatically and it did. One has to assume that stuff breaks, software, disk, RAM, CPU, power supply, anything. The only answer to that is be prepared, build your software to deal with failure (or nicely try to restart), make sure all systems start automatically, have backups, have a plan. For my GSM (telephony) in Smalltalk components I didn't do that yet, mostly because my code was not very mature, I was still building up the trust relationship and so my deployment consisted of manually running GNU screen, then GNU Smalltalk, manually loading my code, starting things up. It was about time to correct that. The tool of choice is the gst-remote application, it will run a GNU Smalltalk image, it can daemonize and it will listen for input from other systems. While moving to this deployment my fellow Smalltalkers were kind enough to fix some bugs on the way. There was an issue of gst-remote exiting when saving an image, the Delay class not functioning properly on resume, the wrong FileDescriptors being closed on image resumption. It is very nice to get help that fast! My deployment now consists of building GNU Smalltalk packages, having a Smalltalk script to load the package and call start method of that package followed by taking a snapshot and exiting. I can then resume the image and if the software is prepared to deal with image resumption it will work. Eval [ | name image | name := Smalltalk arguments first. image := Smalltalk arguments second. (PackageLoader packageAt: name) fileIn; start. ObjectMemory snapshot: image; quit. ] [Less]

Hello, This is an extremely simple XML creator to create simple XML files quickly. The usage is like this: html := XMLNode new: 'html'. body := html add: (XMLNode new: 'body'). body at: 'bgcolor' put: '#ff0000'. h1 := body add: (XMLNode new: ... [More] 'h1'). h1 value: 'My Heading'. p := body add: (XMLNode new: 'p'). p value: 'My paragraph'. html fileOut: '/home/myhome/sample.xml'. Which creates an XML file with the following content: My Heading My paragraph You can download the package via: gst-package --download SimpleXMLCreator -t ~/.st or from: http://www.canol.info/smalltalk/packages/SimpleXMLCreator.star (Non-GNU Smalltalkers can open the star package with their archive manager to look at the code, it is just a zip file) [Less]

Hello, This is an extremely simple XML creator to create simple XML files quickly. The usage is like this: html := XMLNode new: 'html'. body := html add: (XMLNode new: 'body'). body at: 'bgcolor' put: '#ff0000'. h1 := body add: (XMLNode new: ... [More] 'h1'). h1 value: 'My Heading'. p := body add: (XMLNode new: 'p'). p value: 'My paragraph'. html fileOut: '/home/myhome/sample.xml'. Which creates an XML file with the following content: <html> <body bgcolor="#ff0000"> <h1>My Heading</h1> <p>My paragraph</p> </body> </html> You can download the package via: gst-package --download SimpleXMLCreator -t ~/.st or from: http://www.canol.info/smalltalk/packages/SimpleXMLCreator.star (Non-GNU Smalltalkers can open the star package with their archive manager to look at the code, it is just a zip file) [Less]

Hello, This is an extremely simple XML creator to create simple XML files quickly. The usage is like this: html := XMLNode new: 'html'. body := html add: (XMLNode new: 'body'). body at: 'bgcolor' put: '#ff0000'. h1 := body add: (XMLNode new: ... [More] 'h1'). h1 value: 'My Heading'. p := body add: (XMLNode new: 'p'). p value: 'My paragraph'. html fileOut: '/home/myhome/sample.xml'. Which creates an XML file with the following content: <html> <body bgcolor="#ff0000"> <h1>My Heading</h1> <p>My paragraph</p> </body> </html> You can download the package from: http://www.canol.info/smalltalk/SimpleXMLCreator.star (Non-GNU Smalltalkers can open the star package with their archive manager to look at the code, it is just a zip file) [Less]

Let's say you want to put a tool button with a custom image, which is not among the stock items, to the toolbar of your GTK+ application. Here is the code for creating additional stock items from custom images: "Variously sized versions of an image ... [More] is held inside an icon set and icon sets are held inside icon factories. You may put one size of an image inside an icon set and GTK+ will scale it appropriately for your usage." "First create an icon factory." myIconFactory := GtkIconFactory new. "Add that factory as a default icon factory so that the icons inside it can be found by the application." myIconFactory addDefault. "The image we want to create the icon from." myImage := GtkImage newFromFile: 'Path/To/My/Image.png'. "Create an icon set with our image inside. Here we use the convenience method #newFromPixbuf to create an icon set with one image inside." myIconSet := GtkIconSet newFromPixbuf: myImage getPixbuf. "Finally, add our icon set to the icon factory and specify a stock item name for it. It is a convention to add a prefix for your application's custom stock item names." myIconFactory add: 'myprefix-my-icon' iconSet: myIconSet. Now you can use your new stock item like this: GtkToolButton newFromStock: 'myprefix-my-icon'. [Less]

Let's say you want to put a tool button with a custom image, which is not among the stock items, to the toolbar of your GTK+ application. Here is the code for creating additional stock items from custom images: "Variously sized versions of an image ... [More] is held inside an icon set and icon sets are held inside icon factories. You may put one size of an image inside an icon set and GTK+ will scale it appropriately for your usage." "First create an icon factory." myIconFactory := GtkIconFactory new. "Add that factory as a default icon factory so that the icons inside it can be found by the application." myIconFactory addDefault. "The image we want to create the icon from." myImage := GtkImage newFromFile: 'Path/To/My/Image.png'. "Create an icon set with our image inside. Here we use the convenience method #newFromPixbuf to create an icon set with one image inside." myIconSet := GtkIconSet newFromPixbuf: myImage getPixbuf. "Finally, add our icon set to the icon factory and specify a stock item name for it. It is a convention to add a prefix for your application's custom stock item names." myIconFactory add: 'myprefix-my-icon' iconSet: myIconSet. Now you can use your new stock item like this: GtkToolButton newFromStock: 'myprefix-my-icon'. [Less]