- Pharo-dev - lists.pharo.org

Re: [Pharo-project] on Raspberry Pi

by H. Hirzel

Thank you, Stefan for this link giving a list with short explanations of different compatible Smalltalk VMs. I was not aware of it. Especially interesting is the diagram in the history section of http://www.hpi.uni-potsdam.de/hirschfeld/projects/som/ The VM called 'AweSome' implemented in Squeak (includes C++ generator) has 2432 LOC whereas the Java implementation has 5899 LOC. --Hannes On 5/10/12, Stefan Marr <smalltalk(a)stefan-marr.de> wrote: > > On 10 May 2012, at 14:03, H. Hirzel wrote: > >> Yes this is an interesting comparison, in particular if you add size >> and weight to the comparison. >> >> Thank you Marcus, for the idea of doing the comparison putting the >> figures together. >> >> And yes, 1000 times more RAM should make it possible to come up with a >> more easy to understand design for the object memory and VM. > > Have you seen SOM (Simple object machine)? > > That's what you get if you go for simplicity for teaching. > > See http://www.hpi.uni-potsdam.de/hirschfeld/projects/som/, it is originally > coming from Ãrhus. > > It is a nice and clean VM, with little distracting complexity. > Not fast of course... > And, well, not Pharo compatible. (which one could count as a benefit, since > it keeps complexity low) > > Would be interesting to hear what the Pinocchio folks think about it in > terms of complexity. > > > Best regards > Stefan > > > > -- > Stefan Marr > Software Languages Lab > Vrije Universiteit Brussel > Pleinlaan 2 / B-1050 Brussels / Belgium > http://soft.vub.ac.be/~smarr > Phone: +32 2 629 2974 > Fax: +32 2 629 3525 > > >

May 10, 2012

[Pharo-project] I cannot see the code in the latest Moose build

by Fabrizio Perin

Hi, I download the latest yellow build from the moose web site (8 may). When I open Nautilus I cannot see the code. I don't have any clue if it is about Nautilus or about how Nautilus is loaded in Moose or about something else. Any idea? Cheers, Fabrizio

May 10, 2012

Re: [Pharo-project] PHARO_VM on Jenkins

by Igor Stasenko

On 10 May 2012 14:22, Pavel Krivanek <pavel.krivanek(a)gmail.com> wrote: > Hi, > > I got this error on Pharo Kernel 2.0 Jenkins build: > PHARO_VM environment variable is not set. > > Did somebody some VM related changes on Jenkins? > i dont. Probably Christophe. perhaps he removed/changed it in job settings. you can set the environment variables per job. > -- Pavel > -- Best regards, Igor Stasenko.

May 10, 2012

Re: [Pharo-project] PHARO_VM on Jenkins

by Marcus Denker

On May 10, 2012, at 2:23 PM, Pavel Krivanek wrote: > Hi, > > I got this error on Pharo Kernel 2.0 Jenkins build: > PHARO_VM environment variable is not set. > > Did somebody some VM related changes on Jenkins? Yes, Christoph is setting up a mechanism that switches automatically to the last compiled (and successfully tested) VM for all jenkins... Marcus -- Marcus Denker -- http://marcusdenker.de

May 10, 2012

Re: [Pharo-project] on Raspberry Pi

by Stefan Marr

On 10 May 2012, at 14:03, H. Hirzel wrote: > Yes this is an interesting comparison, in particular if you add size > and weight to the comparison. > > Thank you Marcus, for the idea of doing the comparison putting the > figures together. > > And yes, 1000 times more RAM should make it possible to come up with a > more easy to understand design for the object memory and VM. Have you seen SOM (Simple object machine)? That's what you get if you go for simplicity for teaching. See http://www.hpi.uni-potsdam.de/hirschfeld/projects/som/, it is originally coming from Ãrhus. It is a nice and clean VM, with little distracting complexity. Not fast of course... And, well, not Pharo compatible. (which one could count as a benefit, since it keeps complexity low) Would be interesting to hear what the Pinocchio folks think about it in terms of complexity. Best regards Stefan -- Stefan Marr Software Languages Lab Vrije Universiteit Brussel Pleinlaan 2 / B-1050 Brussels / Belgium http://soft.vub.ac.be/~smarr Phone: +32 2 629 2974 Fax: +32 2 629 3525

May 10, 2012

[Pharo-project] student project: a simple recognizer

by stephane ducasse

Hi guys Here is a topic for somebody that would like to have fun with events. There is a javascript version and it would be cool to have a version for Pharo. http://depts.washington.edu/aimgroup/proj/dollar/ http://www.lifl.fr/~casiez/PJE/OneDollar.pdf It is probably close to Genie but at least the algorithms are clearly defined. Stef

May 10, 2012

[Pharo-project] PHARO_VM on Jenkins

by Pavel Krivanek

Hi, I got this error on Pharo Kernel 2.0 Jenkins build: PHARO_VM environment variable is not set. Did somebody some VM related changes on Jenkins? -- Pavel

May 10, 2012

Re: [Pharo-project] FileList efficiency could hardly be worse

by Camillo Bruni

:/ sadly this is not new... see http://code.google.com/p/pharo/issues/detail?id=5316 and http://code.google.com/p/cog/issues/detail?id=73 and I mentioned it in an earlier thread. if you want you can write a fix for this by using the other file primitives (I don't remember the exact name right now) where you access the entries by name instead of by index, which of course avoids looping internally again. I wrote a fix for this under OSX where they weren't implemented... so basically it should work right ahead! btw this implementation is super fun!! Filelist loops => n DiskStore loops => n*(n/2) "in average you loop until you find the proper entry) Primitive loops => n*(n/2)*n "again since you access the stuff by index" best cami On 2012-05-10, at 09:56, Mariano Martinez Peck wrote: > Thanks Nicolas. I would appreciate any effort in this directory since I also have a 10gb package-cache and yes, I know it is slow. > If you can provive a slice :) > > On Thu, May 10, 2012 at 9:44 AM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > :) > > indeed. Imagine my 10 GB package cache. > > Stef > > > On May 10, 2012, at 12:18 AM, Nicolas Cellier wrote: > > > The efficiency of FileList>>listForPattern: is something which should > > deserve a bit more care. > > > > It tries to sort the files, for example by name, but wants to display > > directory first > > ^ [ :x :y | |xIsDir| > > ((xIsDir := x isDirectory) = y isDirectory) > > ifTrue: [ x basename <= y basename ] > > ifFalse: [ > > "directories always precede files" > > xIsDir ]] > > > > Alas, this isDirectory test cost you an arm: > > > > FileReference>>isDirectory > > ^ filesystem isDirectory: path > > > > FileSystem>>isDirectory: aResolvable > > "Resolve the argument, and answer true if the result refers > > to a directory, false if it refers to a file or doesn't exist." > > > > ^ store isDirectory: (self resolve: aResolvable) > > > > FileSystemStore>>isDirectory: aPath > > aPath isRoot ifTrue: [ ^ true ]. > > self > > nodeAt: aPath > > ifPresent: [ :entry | ^ self basicIsDirectory: entry ] > > ifAbsent: [ ^ false ]. > > > > DiskStore>>nodeAt: aPath ifPresent: presentBlock ifAbsent: absentBlock > > | name| > > aPath isRoot ifTrue: [ ^ presentBlock value: self rootNode ]. > > "| encodedPath encodedBasename entry | > > encodedPath := Primitives encode: (self stringFromPath: aPath parent). > > encodedBasename := Primitives encode: aPath basename. > > entry := Primitives lookupDirectory: encodedPath filename: encodedBasename. > > ^ entry == #badDirectoryPath > > ifTrue: absentBlock > > ifFalse: [ > > entry at: 1 put: aPath basename. > > presentBlock value: entry ]." > > name := aPath basename. > > self > > directoryAt: aPath parent > > ifAbsent: absentBlock > > nodesDo: > > [ :entry | > > (self filename: (entry at: 1) matches: name) > > ifTrue: [ ^ presentBlock value: entry ] ]. > > ^ absentBlock value > > > > Arghh, it scans the whole parent directory again! > > If sort is O(n log n), then we transform it into O(2 n^2 log n). > > > > Try to browse your package-cache if you're not a chicken. > > Seriously, it's unusable... > > > > Nicolas > > > > > > > > -- > Mariano > http://marianopeck.wordpress.com >

May 10, 2012

Re: [Pharo-project] on Raspberry Pi

by H. Hirzel

Yes this is an interesting comparison, in particular if you add size and weight to the comparison. Thank you Marcus, for the idea of doing the comparison putting the figures together. And yes, 1000 times more RAM should make it possible to come up with a more easy to understand design for the object memory and VM. --Hannes On 5/10/12, Marcus Denker <marcus.denker(a)inria.fr> wrote: > > On May 10, 2012, at 1:34 PM, H. Hirzel wrote: > >> On 5/10/12, Pavel Krivanek <pavel.krivanek(a)gmail.com> wrote: >>> Hi, >>> >>> one my friend got Raspberry Pi yesterday so I have seen it in action. >>> I had almost no time for experiments but I have seen Fedora 17 on it >>> with standard Squeak (3.10) packages for this distro on FullHD >>> display. On that VM (3.10.5) I got about 40M bytecodes/sec and 1M >>> sends/sec. The environment is not extra fast but usable without >>> problems. I will pray for successful GSoC ARM JIT project :-) The >>> device was connected to the professional meter and the power >>> consumption was about 3.5W. >>> >>> Cheers, >>> -- Pavel >>> >>> >> >> Amazing, a 256MB RAM machine with a main board which includes >> everything for 35USD. >> Some five to seven years ago one would not have believed that this is >> possible. > > > This especially *screams* for re-considering certain design decisions that > we > inherited from Smalltalk. > > 256MB of RAM makes it hard to argue for complex schmemes to save some a > little ram. > (Compact classes, for example). > > How would smalltalk look like if it would be re-designed with the same > philosophy that they > used when there where just 256Kb in the Alto? > > This is a fun comparision: > > http://www.raspberrypi.org/ > vs > http://en.wikipedia.org/wiki/Xerox_Alto > > 1) Price. > > $35 vs. $35000 (est, not adjusted for inflation). x1000 > > 2) RAM > > 256MB vs. 256Kb (max was 512, at the end). x1000 > > 3) CPU > > 1MIPS? not sure. Vs. 700Mhz ARMv11 x 1000 (?) > + 3D and MP4 decoder > > So one could argue that it's a factor of 1 Million considering price > and Performance together... > > > Marcus > > > -- > Marcus Denker -- http://marcusdenker.de > > >

May 10, 2012

Re: [Pharo-project] on Raspberry Pi

by Marcus Denker

On May 10, 2012, at 1:34 PM, H. Hirzel wrote: > On 5/10/12, Pavel Krivanek <pavel.krivanek(a)gmail.com> wrote: >> Hi, >> >> one my friend got Raspberry Pi yesterday so I have seen it in action. >> I had almost no time for experiments but I have seen Fedora 17 on it >> with standard Squeak (3.10) packages for this distro on FullHD >> display. On that VM (3.10.5) I got about 40M bytecodes/sec and 1M >> sends/sec. The environment is not extra fast but usable without >> problems. I will pray for successful GSoC ARM JIT project :-) The >> device was connected to the professional meter and the power >> consumption was about 3.5W. >> >> Cheers, >> -- Pavel >> >> > > Amazing, a 256MB RAM machine with a main board which includes > everything for 35USD. > Some five to seven years ago one would not have believed that this is possible. This especially *screams* for re-considering certain design decisions that we inherited from Smalltalk. 256MB of RAM makes it hard to argue for complex schmemes to save some a little ram. (Compact classes, for example). How would smalltalk look like if it would be re-designed with the same philosophy that they used when there where just 256Kb in the Alto? This is a fun comparision: http://www.raspberrypi.org/ vs http://en.wikipedia.org/wiki/Xerox_Alto 1) Price. $35 vs. $35000 (est, not adjusted for inflation). x1000 2) RAM 256MB vs. 256Kb (max was 512, at the end). x1000 3) CPU 1MIPS? not sure. Vs. 700Mhz ARMv11 x 1000 (?) + 3D and MP4 decoder So one could argue that it's a factor of 1 Million considering price and Performance together... Marcus -- Marcus Denker -- http://marcusdenker.de

May 10, 2012