November 2011 - Pharo-dev - lists.pharo.org

[Pharo-project] Instantiating from a Symbol

by Markus Rother

Hello everybody, I am fairly new to ST and have been following this list since a few weeks. A very brief introduction of myself: I am a 32 year old student of informatics with a degree in political sciences. Currently i am located in Regensburg, Germany. Most of my previous programming was in python, along with some php and javascript. The issue I could not solve on my own is this: I would like to instantiate from symbols. My use-case is a collection of class names which I want to ask to return one instance each. Such that: #Foo asClass new -> a Foo whereas asClass is the method I am looking for. I am using Pharo 1.3. I did not find any description of what I want to achieve on the internet. Many thanks in advance, Markus

Nov. 7, 2011

Re: [Pharo-project] Pharo suffers internal Traffic Jams ...

by Herby VojÄÃk

Norbert Hartl wrote: > >> Guido has a point on one front: slow machines can sometimes expose >> problems that might not otherwise be apparent. It could be as simple as >> highlighting inefficiency or as involved as changing the fraction of time >> the machine spends doing various things. Testing under extreme loads has >> value, and one way to create "load" is to (if only artificially) hobble a >> machine. > > So you are doing it right, Bill. You say it "can" expose problems. That's > true because you change the environmental parameters of the running > program which has the potential to destabilize it. So you might identify a > problem in that scale. What you don't get is an easy conclusion how this > applies to your modern hardware. Assuming that all machines are equal and > just move on the scale slow-fast is a bit naive. Only if you are like that > you can compare an old computer with high load. > Architectures change and the odds are high that you identified a problem > which will never happen if you try it on a different hardware. There are > optimizations that make things just faster. But a lot of optimizations are > based on resource shortage. As much as these optimizations make a system > more usable/reliable on a certain hardware generation as much they might > destabilize the overall system. And some only bring you the gain in a > single hardware generation. > As Igor pointed out above, a testbed is needed. It seems to me that similar situation to hobbling up a machine can appear if there is a lot of concurrent high-load applications running in parallel with Pharo (like 'node -e "for(;;){}"' run on each core). So maybe the question is how is Pharo behaving in such scenarios. On intel Core Duo+ / AMD Athlon 64 X2+. -- View this message in context: http://forum.world.st/Pharo-suffers-internal-Traffic-Jams-tp3995791p3998327… Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

Nov. 7, 2011

Re: [Pharo-project] bootable Pharo image

by Edgar J. De Cleene

On 11/3/11 19:39 PM, "Pavel Krivanek" <pavel.krivanek(a)gmail.com> wrote: > Hi, > > I tried to prepare a bootable Pharo ISO image based on Tiny Core > Linux. Namely on MicroCore (kernel 3.0.3) that was extended with WiFi > support. There is standard Pharo 1.3 image with OSProcess and > CommandShell installed on the Smalltalk side. The resultant image has > about 37 MB. > > Download: > http://www.windmap.cz/playground/pharo/pharo.iso > > If you want to add it directly to your Grub menu, you may do it > without need of extra partition. To the grub.conf add something like: > > title Pharo > root (hd0,1) > kernel /boot/pharo/vmlinuz vga=791 quiet > initrd /boot/pharo/tinycore.gz > > where vmlinuz and tinycore.gz are the only files needed from the ISO image. > > Remastering: > > unpack: > zcat tinycore.gz | sudo cpio -i -H newc -d > > pack: > find | cpio -o -H newc | gzip -2 > ../tinycore.gz > > better compression: > advdef -z4 tinycore.gz > > create ISO (you need unpacked original ISO image): > /bin/cp -pfr tinycore.gz boot > mkdir -p newiso > /bin/cp -pfr boot newiso > mkisofs -l -J -R -V TC-custom -no-emul-boot -boot-load-size 4 \ > -boot-info-table -b boot/isolinux/isolinux.bin \ > -c boot/isolinux/boot.cat -o pharo.iso newiso > > Cheers, > -- Pavel > Pavel: Many things delayed my trial , but today I was able to burn and try the ISO. WWWOOOOOOWWW The most amazing piece of Smalltalk related I saw in a long time. Just returning home from Smalltalks2011 , wish the next year you could come to Argentina and I could thanks in flesh and give you as many beers you like BRAVO Edgar

Nov. 7, 2011

Re: [Pharo-project] Pharo suffers internal Traffic Jams ...

by Igor Stasenko

Squeak 1.0 was released in 1996. In 1995 i puschased my first PC with 150MHz CPU! So, clearly, it was never targeted for platform with such low clock rate. I think even if you take Squeak 1.0 (the root ancestor of Pharo), you will experience problems running it on 50 MHz CPU. Saying that, i don't deny that there are places which can be improved. But we need two things for that: - a motive - a testbed for it you stated the problem(s) but not motives. Even today's handheld devices running at 1GHz clock rate. Also, who should provide a testbed with such constrained environment? Any ideas? As Marcus practically proved: everything which is not tested is broken. So, either we will have testing platform for issues you listed and strong motivation to fix that, or we just keep expanding our own sandbox in direction we see fit :) On 7 November 2011 00:00, Guido Stepken <gstepken(a)googlemail.com> wrote: > >> Reading was not a problem. But I have problems to understand what I am supposed to understand? >> >> Norbert > > You are just coder, no software architect, right? > > Ever tried Pharo 1.3 on a older machine, e.g. P75 with 32 MBytes RAM, some load on Seaside? Funny effects occurring... machine hangs, crashes, spends lots of time in useless functions, unneccessarily locking resouces, memory pumping, eating up resources while waiting for e.g. database answer, spending increasing amount of time (up to 98%) in removing garbage .... > > It's a good way of identifying unmatured software designs. > > Colliding mental models (e.g. event driven vs. polling) > Such things happen, when all members are just coding, fixing, refactoring, without bothering about algorithms, that still work reliable at low memory and high load. > > Pharo at the moment is still very unreliable. > > Sorry to say that! Think about, why FreeBSD works reliably even at a load of 50, whereas other OS stop working. > > regards, Guido Stepken > -- Best regards, Igor Stasenko.

Nov. 7, 2011

Re: [Pharo-project] bootable Pharo image

by S Krish

Agreed, Just wanted to be sure.. but given that TinyCore is GPL.. it will be GPL for the OS part and MIT for the Pharo part.. but thx.. On Sun, Nov 6, 2011 at 9:04 PM, Pavel Krivanek <pavel.krivanek(a)gmail.com>wrote: > License? There is no new code in it except few shell oneliners :-) > Let's say MIT License. > > btw. you can extend it with any tinyCore package. You can simply mount > the package file to the loopback device under squashfs and copy it to > the system root directory. > > mount -o loop -t squashfs pci-utils.tcz outputDirectory > > So you can easily build for example a small image with Chromium etc. > > Cheers, > -- Pavel > > On Sun, Nov 6, 2011 at 2:31 PM, S Krish > <krishnamachari.sudhakar(a)gmail.com> wrote: > > Cool stuff, simple, zipping fast to boot and get to Pharo.. An exciting > > playground to build up Pharo tools for everything to make Pharo the GUI > for > > the tinycore with: > > * Run this with VirtualBox.. build out everything that is needed and > push > > it back as embedded to a device..!.. headless / or headful as reqd. > > What will be the license on this..? Though components are open source.. > > Obliged if Pavel can comment.. > > > > On Fri, Nov 4, 2011 at 1:33 PM, StÃ©phane Ducasse < > stephane.ducasse(a)inria.fr> > > wrote: > >> > >> thanks pavel. > >> Jean-Baptiste may be this can be interesting for your project > >> > >> > >> On Nov 3, 2011, at 11:39 PM, Pavel Krivanek wrote: > >> > >> > Hi, > >> > > >> > I tried to prepare a bootable Pharo ISO image based on Tiny Core > >> > Linux. Namely on MicroCore (kernel 3.0.3) that was extended with WiFi > >> > support. There is standard Pharo 1.3 image with OSProcess and > >> > CommandShell installed on the Smalltalk side. The resultant image has > >> > about 37 MB. > >> > > >> > Download: > >> > http://www.windmap.cz/playground/pharo/pharo.iso > >> > > >> > If you want to add it directly to your Grub menu, you may do it > >> > without need of extra partition. To the grub.conf add something like: > >> > > >> > title Pharo > >> > root (hd0,1) > >> > kernel /boot/pharo/vmlinuz vga=791 quiet > >> > initrd /boot/pharo/tinycore.gz > >> > > >> > where vmlinuz and tinycore.gz are the only files needed from the ISO > >> > image. > >> > > >> > Remastering: > >> > > >> > unpack: > >> > zcat tinycore.gz | sudo cpio -i -H newc -d > >> > > >> > pack: > >> > find | cpio -o -H newc | gzip -2 > ../tinycore.gz > >> > > >> > better compression: > >> > advdef -z4 tinycore.gz > >> > > >> > create ISO (you need unpacked original ISO image): > >> > /bin/cp -pfr tinycore.gz boot > >> > mkdir -p newiso > >> > /bin/cp -pfr boot newiso > >> > mkisofs -l -J -R -V TC-custom -no-emul-boot -boot-load-size 4 \ > >> > -boot-info-table -b boot/isolinux/isolinux.bin \ > >> > -c boot/isolinux/boot.cat -o pharo.iso newiso > >> > > >> > Cheers, > >> > -- Pavel > >> > > >> > >> > > > > > >

Nov. 7, 2011

Re: [Pharo-project] Pharo suffers internal Traffic Jams ...

by Norbert Hartl

Bill, don't take my email too serious. I just tried to meet the same level when replying to the original author. Am 07.11.2011 um 01:18 schrieb Schwab,Wilhelm K: > Norbert, > > Guido has a point on one front: slow machines can sometimes expose problems that might not otherwise be apparent. It could be as simple as highlighting inefficiency or as involved as changing the fraction of time the machine spends doing various things. Testing under extreme loads has value, and one way to create "load" is to (if only artificially) hobble a machine. > So you are doing it right, Bill. You say it "can" expose problems. That's true because you change the environmental parameters of the running program which has the potential to destabilize it. So you might identify a problem in that scale. What you don't get is an easy conclusion how this applies to your modern hardware. Assuming that all machines are equal and just move on the scale slow-fast is a bit naive. Only if you are like that you can compare an old computer with high load. Architectures change and the odds are high that you identified a problem which will never happen if you try it on a different hardware. There are optimizations that make things just faster. But a lot of optimizations are based on resource shortage. As much as these optimizations make a system more usable/reliable on a certain hardware generation as much they might destabilize the overall system. And some only bring you the gain in a single hardware generation. So my response is more targetted to the fact that the author is capable of demanding things from this community to care about a problem he made up based on his own weak assumptions. No prove, nothing concrete to talk about. Just complains and demands for weird things like the need to "analytically identifying" "unpredictable" things??? Come on! > I will distance myself from personal attacks on Stef and blanket smears of the processes and hard work that have brought Pharo to its current state. Agreed. To build a community you need to get rid of some of your own ego effects. Maybe that's a reason why ego based mails have a huge potential to harm such a community. Hmmm, but then I didn't do any better in replying :) Rats! Norbert > > ________________________________________ > From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] on behalf of Norbert Hartl [norbert(a)hartl.name] > Sent: Sunday, November 06, 2011 6:32 PM > To: Pharo-project(a)lists.gforge.inria.fr > Subject: Re: [Pharo-project] Pharo suffers internal Traffic Jams ... > > Am 07.11.2011 um 00:00 schrieb Guido Stepken: > >> >>> Reading was not a problem. But I have problems to understand what I am supposed to understand? >>> >>> Norbert >> >> You are just coder, no software architect, right? >> > What is the difference? > >> Ever tried Pharo 1.3 on a older machine, e.g. P75 with 32 MBytes RAM, some load on Seaside? Funny effects occurring... machine hangs, crashes, spends lots of time in useless functions, unneccessarily locking resouces, memory pumping, eating up resources while waiting for e.g. database answer, spending increasing amount of time (up to 98%) in removing garbage .... >> > I need to think a little while to come up with a single reason why I should do this. I'll come back to you if I find some. But don't wait for it. > >> It's a good way of identifying unmatured software designs. >> > Yes, and spending most of your time on non-realistic cases and yagni makes you just a bad developer. > >> Colliding mental models (e.g. event driven vs. polling) >> Such things happen, when all members are just coding, fixing, refactoring, without bothering about algorithms, that still work reliable at low memory and high load. >> > Ok, how clever are you if you design your machines to have too low memory and suffer from high load? If I recap you are saying that the reason you need to be a good software architect is because you are a bad system architect? If that's right why you don't just learn a little bit about system architecture? > >> Pharo at the moment is still very unreliable. >> >> Sorry to say that! Think about, why FreeBSD works reliably even at a load of 50, whereas other OS stop working. >> > Explain it to me, please! > > Norbert >

Nov. 7, 2011

Re: [Pharo-project] Pharo suffers internal Traffic Jams ...

by Schwab,Wilhelm K

Norbert, Guido has a point on one front: slow machines can sometimes expose problems that might not otherwise be apparent. It could be as simple as highlighting inefficiency or as involved as changing the fraction of time the machine spends doing various things. Testing under extreme loads has value, and one way to create "load" is to (if only artificially) hobble a machine. I will distance myself from personal attacks on Stef and blanket smears of the processes and hard work that have brought Pharo to its current state. Bill ________________________________________ From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] on behalf of Norbert Hartl [norbert(a)hartl.name] Sent: Sunday, November 06, 2011 6:32 PM To: Pharo-project(a)lists.gforge.inria.fr Subject: Re: [Pharo-project] Pharo suffers internal Traffic Jams ... Am 07.11.2011 um 00:00 schrieb Guido Stepken: > >> Reading was not a problem. But I have problems to understand what I am supposed to understand? >> >> Norbert > > You are just coder, no software architect, right? > What is the difference? > Ever tried Pharo 1.3 on a older machine, e.g. P75 with 32 MBytes RAM, some load on Seaside? Funny effects occurring... machine hangs, crashes, spends lots of time in useless functions, unneccessarily locking resouces, memory pumping, eating up resources while waiting for e.g. database answer, spending increasing amount of time (up to 98%) in removing garbage .... > I need to think a little while to come up with a single reason why I should do this. I'll come back to you if I find some. But don't wait for it. > It's a good way of identifying unmatured software designs. > Yes, and spending most of your time on non-realistic cases and yagni makes you just a bad developer. > Colliding mental models (e.g. event driven vs. polling) > Such things happen, when all members are just coding, fixing, refactoring, without bothering about algorithms, that still work reliable at low memory and high load. > Ok, how clever are you if you design your machines to have too low memory and suffer from high load? If I recap you are saying that the reason you need to be a good software architect is because you are a bad system architect? If that's right why you don't just learn a little bit about system architecture? > Pharo at the moment is still very unreliable. > > Sorry to say that! Think about, why FreeBSD works reliably even at a load of 50, whereas other OS stop working. > Explain it to me, please! Norbert

Nov. 7, 2011

Re: [Pharo-project] Pharo suffers internal Traffic Jams ...

by Schwab,Wilhelm K

Guido, I doubt anyone here would say that Pharo is perfect, but "very unreliable???" That is simply not true. There is polling, and there should not be - I am probably as outspoken as any on that point. Overall, Pharo works very well and is being improved on multiple fronts. Bill ________________________________________ From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] on behalf of Guido Stepken [gstepken(a)googlemail.com] Sent: Sunday, November 06, 2011 6:00 PM To: Pharo-project(a)lists.gforge.inria.fr Subject: Re: [Pharo-project] Pharo suffers internal Traffic Jams ... > Reading was not a problem. But I have problems to understand what I am supposed to understand? > > Norbert You are just coder, no software architect, right? Ever tried Pharo 1.3 on a older machine, e.g. P75 with 32 MBytes RAM, some load on Seaside? Funny effects occurring... machine hangs, crashes, spends lots of time in useless functions, unneccessarily locking resouces, memory pumping, eating up resources while waiting for e.g. database answer, spending increasing amount of time (up to 98%) in removing garbage .... It's a good way of identifying unmatured software designs. Colliding mental models (e.g. event driven vs. polling) Such things happen, when all members are just coding, fixing, refactoring, without bothering about algorithms, that still work reliable at low memory and high load. Pharo at the moment is still very unreliable. Sorry to say that! Think about, why FreeBSD works reliably even at a load of 50, whereas other OS stop working. regards, Guido Stepken

Nov. 7, 2011

Re: [Pharo-project] Pharo suffers internal Traffic Jams ...

by Herby VojÄÃk

Guido Stepken wrote: > > You are just coder, no software architect, right? > Eh?! I am really shocked. I would never imagine that something like this can happen. But it obviously did. What about career change? You may earn a million by teaching courses of Arrogant Pride, won't you? -- View this message in context: http://forum.world.st/Pharo-suffers-internal-Traffic-Jams-tp3995791p3997047… Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

Nov. 6, 2011

Re: [Pharo-project] Pharo suffers internal Traffic Jams ...

by Norbert Hartl

Am 07.11.2011 um 00:25 schrieb Guido Stepken: > >> Life is short and good for positive energy. >> >> Stef > > How do i code that "positive energy" in Pharo without periodically crashing the systen? "FreeHugsClass" with extra positive energy spending methods? > That's a lesson you have to tackle on your own, my young apprentice! Norbert >> >> On Nov 7, 2011, at 12:00 AM, Guido Stepken wrote: >> >>> >>>> Reading was not a problem. But I have problems to understand what I am supposed to understand? >>>> >>>> Norbert >>> >>> You are just coder, no software architect, right? >>> >>> Ever tried Pharo 1.3 on a older machine, e.g. P75 with 32 MBytes RAM, some load on Seaside? Funny effects occurring... machine hangs, crashes, spends lots of time in useless functions, unneccessarily locking resouces, memory pumping, eating up resources while waiting for e.g. database answer, spending increasing amount of time (up to 98%) in removing garbage .... >>> >>> It's a good way of identifying unmatured software designs. >>> >>> Colliding mental models (e.g. event driven vs. polling) >>> Such things happen, when all members are just coding, fixing, refactoring, without bothering about algorithms, that still work reliable at low memory and high load. >>> >>> Pharo at the moment is still very unreliable. >>> >>> Sorry to say that! Think about, why FreeBSD works reliably even at a load of 50, whereas other OS stop working. >>> >>> regards, Guido Stepken >> >> >

Nov. 6, 2011