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

Re: [Pharo-project] OT: Dart

by StÃ©phane Ducasse

Indeed I always felt stupid :) But now I also want a mall kernel and scripting syntax (and a image one demand only). So :) Stef > > Note one sneaky thing: using an image as means of deployment: > http://www.infoq.com/news/2011/10/google-dart-language mentions "Dart > comes with tools to create an image of the heap of an application and > package it into an optimized format which can be loaded nearly > instantly, reminiscient of Smalltalk's image system." > > Funny, given the number of arguments Smalltalkers have with people > over the use of images. > > frank > >> On 10 October 2011 14:43, Pavel Krivanek <pavel.krivanek(a)gmail.com> wrote: >>> Hi, >>> >>> Google published the first information about Dart: >>> http://www.dartlang.org/ >>> >>> Cheers, >>> -- Pavel >>> >>> >> >> >> >> -- >> Best regards, >> Igor Stasenko. >> >> >

Oct. 10, 2011

[Pharo-project] new Cog VM available at...

by Eliot Miranda

http://www.mirandabanda.org/files/Cog/VM/VM.r2499/. CogVM binaries as per VMMaker.oscog-eem.133/r2499. Tiny performance tweak to bytecodePrimMultiply. Added findStringBeginningWith: debugging facility. Fix yet another slip in Cogit>>lookup:for:methodAndErrorSelectorInto: for cannotInterpret: cases. Fixes Mariano's crash as of 2011/10/03. Add -numextsems command-line argument to set size of external semaphore table on start-up. Enjoy -- best, Eliot

Oct. 10, 2011

Re: [Pharo-project] When will Fuel file format stabilize?

by Javier PimÃ¡s

Maybe the way to go is to provide a metadescription of the changes done to the format since last version. That way, you can use it to convert your serialized objects from one version to another (even back and forward). That's what I think databases do, if you update your version, you have to update the database. It seems like a less effort approach. Cheers! Pocho. On Mon, Oct 10, 2011 at 1:50 PM, Yanni Chiu <yanni(a)rogers.com> wrote: > On 08/10/11 6:03 PM, StÃ©phane Ducasse wrote: > >> Mariano >> >> >> No, that's impossible, and if posible, it is not worth it. >>> Migrating from an old format to a new one is extremelly complicated >>> and innecessary. The easiest way to solve this is to take the >>> correct version of Fuel, materialize the graph from the stream, >>> load new version of Fuel, and seriaize it again. That the easiest, >>> more secure, and more practical approach I can see. >>> >> >> It would be interesting to see if you can get two different versions >> in memory :) (a need for a module system) so that you can load with >> one and save with the other. >> > > For the case where a lot of serialized files need to be converted, having > two versions in memory is almost a necessity; otherwise, the Fuel code > update would have to be applied for each file being converted. > > A separate issue is that at some point I wanted to serialize something > differently, in two different contexts. In one case, serializing a Pier > kernel, I want Fuel to just do its thing. In the other case, when exporting > a portion a Pier kernel, I want to fine tune (i.e. map to different objects) > the objects being exported/imported. There is a hook to allow the object > swap, but the swap would then take place for the other case of serializing > to whole kernel (where the desired behaviour was for no such mapping). > > -- > Yanni > > > -- Lic. Javier PimÃ¡s Ciudad de Buenos Aires

Oct. 10, 2011

Re: [Pharo-project] Too many semaphores, image blocked

by Eliot Miranda

On Sat, Oct 8, 2011 at 12:13 PM, Igor Stasenko <siguctua(a)gmail.com> wrote: > On 7 October 2011 23:38, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: > > > > > > On Fri, Oct 7, 2011 at 1:30 PM, Igor Stasenko <siguctua(a)gmail.com> > wrote: > >> > >> I don't understand why this problem appear only recently, and if i > >> remember before i never heard that people > >> had a problems with too many open sockets (and consequently exceeding > >> a semaphore table space). > >> > >> Is there something we changed in language? in VM? or is it purely > >> because we are lagging behind the scale of > >> projects which today running on pharo? :) > > > > In the VM. In Cog I implemented a thread-safe non-blocking signal > external > > semaphore facility but I was too lazy to implement a thread-safe > > non-blocking growing facility. It seems simple to set the size at > start-up. > > You choose a value large enough for your application, set it, save the > > image and you're done. Whereas implementing a non-blocking growing > facility > > is tricky. > >> > Hmm, that confuses me even more. > > In Squeak VM there is a single hard limit for SemaphoresToSignalA, and > SemaphoresToSignalB > tables - 500 (i dont remember correct name of these tables). > > In these tables, upon receiving a signal, it storing the index of > semaphore to signal, when you using signalSemaphore() function. > Then at interrupt time, these tables are flushed by signaling > corresponding semaphores which are stored in external semaphore table > under corresponding index. > This means that between two interrupts you cannot signal more than 500 > semaphores. And given that time between interrupts are pretty small > (about 1 ms) i hardly beleive that you can put such high load on > server to receive more than 500 signals in 1 ms time period. > That's not quite how it works. Each location in the VM's table maps to one semaphore in the image (each location remembers the number of signals to send to each external semaphore). So it's not the number of signals, it's the number of external semaphores in use. So the problem is not here, apparently, the problem is in size of > external semaphore table , where semaphore objects are stored, > which growth can be controlled completely by image size (this is a > simple array), because signaling machinery operating only with indexes > in this table but not with actual semaphores. > > Now, since i don't know well how much changes you did in signaling > code in Cog. I only suspect that your conclusion that your changes > might > cause the problems are wrong. > Could be. In any case, a command-line parameter does not harm :) > > > > > -- > > best, > > Eliot > > > > > > -- > Best regards, > Igor Stasenko. > > -- best, Eliot

Oct. 10, 2011

[Pharo-project] CogDroid Status Update

by Dimitry Golubovsky

Hi, I would like to update the Squeak/Pharo community on the CogDroid development status, summarize the changes made since the first public alpha release, and discuss further directions of the development. I have uploaded two new alpha release packages: for ARM devices: http://squeakvm-tablet.googlecode.com/files/CogDroid-alpha-20111009.apk for Android-x86: http://squeakvm-tablet.googlecode.com/files/CogDroid86-alpha-20111010.apk I have created a wiki page [1] which summarizes the changes made to CogDroid since the first public alpha release. Briefly, these changes are: - Partial integration with Android intent system, so CogDroid can be launched with a specified Smalltalk image file and a startup script by tapping a home screen shortcut icon. Such icons can be created from Smalltalk code running in CogDroid. See also [2] for technical details. - Added build for the x86 Android platform. Android-x86 can run on Intel-compatible CPUs in desktops and netbooks, and also in virtual machines. - Using a PC with physical keyboard and mouse attached brings some benefits in terms of user input, so functionality was added to support special keys such as Ctrl- and Shift- modifiers, and also arrow and home/end keys. This may be also of use on ARM tablets with keyboard and mouse attached, or on dockable phones. I am unable to test this myself, but your feedback is always welcome. At this moment, I am going to change the direction of my efforts towards deeper studying of Android itself, which may give me some ideas how to integrate CogDroid better with Android services (e. g. sound interface is an open question, but I need to study more, whether OSS/ALSA is available under the hood, or some Java wrapper is needed). This means that for some time I will be pushing updates less frequently, except for bugs and critical issues, if reported. OTOH this is a better time to integrate my developer's branch with the mainline. So, Igor and Eliot please contact me to discuss the technical moments. I would like to thank the whole Squeak/Pharo community for helping me with the development and testing. The Benchmark page [3] is a source of information people may find helpful choosing an Android device to run CogDroid on. Your feedback is always welcome. Please add your comments to the Alpha Progress page [1], including your ideas of Android applications that might be created with CogDroid, and what functionality you think needs to be added. Thanks again, and hope to hear from you! ------------------- [1] http://code.google.com/p/squeakvm-tablet/wiki/CogDroidAlphaProgress [2] http://code.google.com/p/squeakvm-tablet/wiki/CogDroidIntentsAndShortcuts [3] http://code.google.com/p/squeakvm-tablet/wiki/TinyBenchmark -- Dimitry Golubovsky Anywhere on the Web

Oct. 10, 2011

Re: [Pharo-project] OT: Dart

by Denis Kudriashov

2011/10/10 Igor Stasenko <siguctua(a)gmail.com> > Seems so. Except that fuel can contain data "objects" not just code > "objects". > > Okay, 10 years later i hope we again have a new language, which will > inherit all current crap + > finally "everything is an object" concept :) > > Really? I dont see that classes are objects in dart and can be assigned to variables.

Oct. 10, 2011

Re: [Pharo-project] When will Fuel file format stabilize?

by Yanni Chiu

On 08/10/11 6:03 PM, StÃ©phane Ducasse wrote: > Mariano > > >> No, that's impossible, and if posible, it is not worth it. >> Migrating from an old format to a new one is extremelly complicated >> and innecessary. The easiest way to solve this is to take the >> correct version of Fuel, materialize the graph from the stream, >> load new version of Fuel, and seriaize it again. That the easiest, >> more secure, and more practical approach I can see. > > It would be interesting to see if you can get two different versions > in memory :) (a need for a module system) so that you can load with > one and save with the other. For the case where a lot of serialized files need to be converted, having two versions in memory is almost a necessity; otherwise, the Fuel code update would have to be applied for each file being converted. A separate issue is that at some point I wanted to serialize something differently, in two different contexts. In one case, serializing a Pier kernel, I want Fuel to just do its thing. In the other case, when exporting a portion a Pier kernel, I want to fine tune (i.e. map to different objects) the objects being exported/imported. There is a hook to allow the object swap, but the swap would then take place for the other case of serializing to whole kernel (where the desired behaviour was for no such mapping). -- Yanni

Oct. 10, 2011

Re: [Pharo-project] OT: Dart

by Igor Stasenko

On 10 October 2011 18:16, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: > > > On Mon, Oct 10, 2011 at 7:34 AM, Mariano Martinez Peck > <marianopeck(a)gmail.com> wrote: >> >> >> On Mon, Oct 10, 2011 at 3:58 PM, Frank Shearar <frank.shearar(a)gmail.com> >> wrote: >>> >>> On 10 October 2011 14:22, Igor Stasenko <siguctua(a)gmail.com> wrote: >>> > My first impression: >>> > Â - a cross-breeding of C and .... C and a bit of C.. and then C on top. >>> > >>> > And i bet it is implemented in C >>> > :D >>> >>> You mean C#, of course. C#, with a side order of share-nothing message >>> passing concurrency. C# on the whole isn't a bad language: it's way >>> better than Java (which isn't, admittedly, exactly a high bar). >>> >>> But still, Dart seems like nothing to write home about. >>> >>> Note one sneaky thing: using an image as means of deployment: >>> http://www.infoq.com/news/2011/10/google-dart-language mentions "Dart >>> comes with tools to create an image of the heap of an application and >>> package it into an optimized format which can be loaded nearly >>> instantly, reminiscient of Smalltalk's image system." >>> >> >> A couple of hours ago, I have asked this: >> https://groups.google.com/a/dartlang.org/group/misc/browse_thread/thread/fd… > > You was Gilad's reply? > > Hi Mariano, > > On Mon, Oct 10, 2011 at 5:55 AM, Mariano Martinez Peck < > > marianop...(a)gmail.com> wrote: > >> So I wonder...is this a kind of Smalltalk image? what is similar andÂ what >> different? > > Better analog is a Strongtalk BST file. It contains the classes > andÂ compile-time constants, but no state. > > -- > Cheers, Gilad > > And as I understand it a BST file is pretty much the same intent as a parcel > or a fuel package containing code. > Seems so. Except that fuel can contain data "objects" not just code "objects". Okay, 10 years later i hope we again have a new language, which will inherit all current crap + finally "everything is an object" concept :) -- Best regards, Igor Stasenko.

Oct. 10, 2011

Re: [Pharo-project] OT: Dart

by Eliot Miranda

On Mon, Oct 10, 2011 at 7:34 AM, Mariano Martinez Peck < marianopeck(a)gmail.com> wrote: > > > On Mon, Oct 10, 2011 at 3:58 PM, Frank Shearar <frank.shearar(a)gmail.com>wrote: > >> On 10 October 2011 14:22, Igor Stasenko <siguctua(a)gmail.com> wrote: >> > My first impression: >> > - a cross-breeding of C and .... C and a bit of C.. and then C on top. >> > >> > And i bet it is implemented in C >> > :D >> >> You mean C#, of course. C#, with a side order of share-nothing message >> passing concurrency. C# on the whole isn't a bad language: it's way >> better than Java (which isn't, admittedly, exactly a high bar). >> >> But still, Dart seems like nothing to write home about. >> >> Note one sneaky thing: using an image as means of deployment: >> http://www.infoq.com/news/2011/10/google-dart-language mentions "Dart >> comes with tools to create an image of the heap of an application and >> package it into an optimized format which can be loaded nearly >> instantly, reminiscient of Smalltalk's image system." >> >> > A couple of hours ago, I have asked this: > https://groups.google.com/a/dartlang.org/group/misc/browse_thread/thread/fd… > You was Gilad's reply? Hi Mariano, On Mon, Oct 10, 2011 at 5:55 AM, Mariano Martinez Peck < marianop...<https://groups.google.com/a/dartlang.org/groups/unlock?_done=/a/dartlang.or…> @gmail.com> wrote: > So I wonder...is this a kind of Smalltalk image? what is similar and what different? Better analog is a Strongtalk BST file. It contains the classes and compile-time constants, but no state. -- Cheers, Gilad And as I understand it a BST file is pretty much the same intent as a parcel or a fuel package containing code. > > > >> Funny, given the number of arguments Smalltalkers have with people >> over the use of images. >> >> frank >> >> > On 10 October 2011 14:43, Pavel Krivanek <pavel.krivanek(a)gmail.com> >> wrote: >> >> Hi, >> >> >> >> Google published the first information about Dart: >> >> http://www.dartlang.org/ >> >> >> >> Cheers, >> >> -- Pavel >> >> >> >> >> > >> > >> > >> > -- >> > Best regards, >> > Igor Stasenko. >> > >> > >> >> > > > -- > Mariano > http://marianopeck.wordpress.com > > -- best, Eliot

Oct. 10, 2011

Re: [Pharo-project] OT: Dart

by Denis Kudriashov

Interesting, Do they (darters) see Amber? 2011/10/10 Mariano Martinez Peck <marianopeck(a)gmail.com> > > > On Mon, Oct 10, 2011 at 3:58 PM, Frank Shearar <frank.shearar(a)gmail.com>wrote: > >> On 10 October 2011 14:22, Igor Stasenko <siguctua(a)gmail.com> wrote: >> > My first impression: >> > - a cross-breeding of C and .... C and a bit of C.. and then C on top. >> > >> > And i bet it is implemented in C >> > :D >> >> You mean C#, of course. C#, with a side order of share-nothing message >> passing concurrency. C# on the whole isn't a bad language: it's way >> better than Java (which isn't, admittedly, exactly a high bar). >> >> But still, Dart seems like nothing to write home about. >> >> Note one sneaky thing: using an image as means of deployment: >> http://www.infoq.com/news/2011/10/google-dart-language mentions "Dart >> comes with tools to create an image of the heap of an application and >> package it into an optimized format which can be loaded nearly >> instantly, reminiscient of Smalltalk's image system." >> >> > A couple of hours ago, I have asked this: > https://groups.google.com/a/dartlang.org/group/misc/browse_thread/thread/fd… > > >> Funny, given the number of arguments Smalltalkers have with people >> over the use of images. >> >> frank >> >> > On 10 October 2011 14:43, Pavel Krivanek <pavel.krivanek(a)gmail.com> >> wrote: >> >> Hi, >> >> >> >> Google published the first information about Dart: >> >> http://www.dartlang.org/ >> >> >> >> Cheers, >> >> -- Pavel >> >> >> >> >> > >> > >> > >> > -- >> > Best regards, >> > Igor Stasenko. >> > >> > >> >> > > > -- > Mariano > http://marianopeck.wordpress.com > >

Oct. 10, 2011