- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] [pharo-project/pharo-core]

by Marcus Denker

On 29 Apr 2014, at 16:13, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: > Hi Marcus, > > > On Apr 29, 2014, at 6:31 AM, Marcus Denker <marcus.denker(a)inria.fr> wrote: > >> >> On 29 Apr 2014, at 15:29, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: >> >>> Without any information on what has been changed these GitHub messages are almost pure noise. It's more than tedious to expect someone to follow the link to get more info. Can the system not include at least the commit comment? >> >> There are two mails: >> >> 1) useless >> 2) it has *everything* >> -> changed methods and classes >> -> commit comments >> -> Link to get the diffs very nicely formatted. >> >> Sadly we did not find a way to turn of this one useless mail. There is sadly no option. > > So who develops github? Github inc. they have now >10 million repositories. got 100mill funding in 2012â¦ > Are they willing to provide a third option? Unlikely, considering the scale of the operation. > Another potential solution would be to direct the full commit to a server that filters/edits down the full messages and resends. > Yes, I was thinking about thatâ¦ but who has the time? > Personally I'd like to keep up with the GitHub commits through email but right now I just delete them. I could filter them out but that's no better. :-( > >> >>> Eliot (phone) >>> >>> On Apr 29, 2014, at 4:12 AM, GitHub <noreply(a)github.com> wrote: >>> >>>> Branch: refs/tags/30843 >>>> Home: https://github.com/pharo-project/pharo-core >> >> >

April 30, 2014

Re: [Pharo-dev] [Fuel] Serialize and materialize to GZip

by Mariano Martinez Peck

On Wed, Apr 30, 2014 at 6:33 AM, roberto.minelli(a)usi.ch < roberto.minelli(a)usi.ch> wrote: > Hi, > > Following the Fuel test FLUserGuidesTest>>#testGZip I discovered that I > can serialize and materialize to and from GZip archives. Cool! > > I tried with some small test object and it worked like a charm. When I > tried with a large objectâ¦ > > Yes, I have the exact same problem long ago. As far as I could debug at that point in time, it was a bug in the compression plugin in the VM. So there isn't anything easy you can do about. See http://lists.gforge.inria.fr/pipermail/pharo-project/2011-December/056419.h… for more details. > Serialization > - It does not work, the image instantly crashes > > Materialization > - Since I was not able to serialize the large object on GZip, I serialized > "normally" than compressed the resulting fuel file using GZipWriteStream > class>>#compressFile: > - When I materialize from the GZip archive, it takes forever and does not > succeed after more than 1 minute. Note that the same non-Gzipped file takes > a couple of seconds to be materialized. > > If you serialized normally and the compressed, then to materialize you need to first uncompress and then give fuel the decompressed version. BTW...what I did for Fuel and compressing is a Pharo binding to a really fast compressor/uncompressor: LZ4. http://smalltalkhub.com/#!/~marianopeck/LZ4 That is very fast, but it doesn't provide a streaming API. So the usage I did was: - Fuel serialize in memory to a bytearray - LZ4 compress that bytearray and write compressed to file or whatever you want - LZ4 uncompress from file or from where you stored the compressed version. - Fuel materialize from the compressed stream from previous step this will work even for very large graphs. There is also an experiment Max and I were doing about compressing strings right inside Fuel: https://code.google.com/p/fuel/issues/detail?id=160 But this is committed in the experiments repo. If you want to take a look... Best, -- Mariano http://marianopeck.wordpress.com

April 30, 2014

Re: [Pharo-dev] SuffixConditionals

by Sean P. DeNigris

Torsten Bergmann wrote > SuffixConditionals adds #if: and #unless methods to BlockClosure. > Currently in VisualWorks but can be ported to other Smalltalks (like > Pharo) as well. Good idea! It is MIT and would be a great bridge for a Ruby community in the spirit of http://forum.world.st/a-Pharo-talk-from-a-ruby-conference-tp4756805p4757055… : FAQ Q: ifTrue: and ifFalse: look weird to me. Why can't I have more readable control flow statements like Ruby? A: You can! Simply load SuffixConditionals from the Configuration Browser and you can write things like: [process stop] if: process isRunning and [process start] unless: process isRunning Also would be a great answer when this inevitably comes up in the endless "why isn't Smalltalk as popular as Ruby" conversations (http://stackoverflow.com/a/438986/424245) ----- Cheers, Sean -- View this message in context: http://forum.world.st/SuffixConditionals-tp4757183p4757212.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

April 30, 2014

Re: [Pharo-dev] Pen back in the image

by Sean P. DeNigris

philippeback wrote > I'd like to see the Pen class coming back in the main image. Answered at https://stackoverflow.com/questions/22737674/wheres-the-pen-class-in-pharo Gofer it squeaksource: 'PharoNonCorePackages'; package: 'BitBltPen'; load. Then you can "Display restoreAfter: [Pen example]" HTH ----- Cheers, Sean -- View this message in context: http://forum.world.st/Pen-back-in-the-image-tp4751190p4757210.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

April 30, 2014

Re: [Pharo-dev] Pharo on RPi

by Goubier Thierry

Thanks JB! This is really great! Thierry Le 30/04/2014 13:18, Jean Baptiste Arnaud a Ã©crit : > The status of Rpi. > The VM work as a StackVM linux one, > Except for: > - Sound (recent bug will be fixed soon), > - NativeBoost (arm), > - FFI (recent change from Doug will be here soon) > and OsProcess (I just don not try it yet but I didn't look at it). > > > I think the VM is stable enough to be used. > I will move the infrastructure to the file server today, the last > raspberry pi VM should work. > It will be fixed during the day. > > > > On 30 Apr 2014, at 12:31, Goubier Thierry <thierry.goubier(a)cea.fr > <mailto:thierry.goubier@cea.fr>> wrote: > >> >> >> Le 30/04/2014 11:58, jannik laval a Ã©crit : >>> I have a Phratch that begin to work on RPi >>> (https://ci.inria.fr/pharo-contribution/view/Phratch/job/Phratch-OneClick-RP…) >>> So, you can probably use Pharo 3 >> >> Thanks. >> >> I'll start moving the infrastructure there then. >> >> Thierry >> >>> Now I have problems with FileSystem, I will ask in another thread. >> >>> Jannik >>> >>> -- >>> >>> ~~Jannik Laval~~ >>> Ãcole des Mines de Douai >>> Enseignant-chercheur >>> http://www.jannik-laval.eu >>> http://www.phratch.com >>> http://car.mines-douai.fr/ >>> >> >> -- >> Thierry Goubier >> CEA list >> Laboratoire des Fondations des SystÃ¨mes Temps RÃ©el EmbarquÃ©s >> 91191 Gif sur Yvette Cedex >> France >> Phone/Fax: +33 (0) 1 69 08 32 92 / 83 95 >> > > > > Best Regards > Jean Baptiste Arnaud > jbaptiste.arnaud(a)gmail.com <mailto:jbaptiste.arnaud@gmail.com> > > > > > > > -- Thierry Goubier CEA list Laboratoire des Fondations des SystÃ¨mes Temps RÃ©el EmbarquÃ©s 91191 Gif sur Yvette Cedex France Phone/Fax: +33 (0) 1 69 08 32 92 / 83 95

April 30, 2014

Re: [Pharo-dev] Pharo RPi and FileSystem error

by Jean Baptiste Arnaud

This bug turn around since the first release of Rpi VM, It can be solve completely in the image side by just patching it. Until we have a better solution. We used in the 3.0 image NativeBoost to get all the env variable. So when you ask origin it try NativeBoost, that do not work. And UnixResolver raises this exception. There are no NativeBoost on Rpi, FFI or OSProcess. Basically the fileSystem work, but some data are fetch via env variable and then NativeBoost. The solution is to bypass all the request of env variable. You should use another way until, we finish to integrate a way to request correctly the env variable (NB on arm). I will studies the possibility to reintegrate fast the OSProcess plugin to offer "better" solution. But here we will have a special case for the UnixResolver isNBWorkingOnThisVM. That will be remove when the asmjit arm will be finish. On 30 Apr 2014, at 12:01, jannik laval <jannik.laval(a)gmail.com> wrote: > Hi all, > > I have an error on Pharo 3, with RPi. > The error is UnixResolver>>Can't find the request origin > > To reproduce it, just run this line: > --- > FileLocator home exists > > > Thank you for your help. > -- > ~~Jannik Laval~~ > Ãcole des Mines de Douai > Enseignant-chercheur > http://www.jannik-laval.eu > http://www.phratch.com > http://car.mines-douai.fr/ > Best Regards Jean Baptiste Arnaud jbaptiste.arnaud(a)gmail.com

April 30, 2014

Re: [Pharo-dev] Pharo on RPi

by Jean Baptiste Arnaud

The status of Rpi. The VM work as a StackVM linux one, Except for: - Sound (recent bug will be fixed soon), - NativeBoost (arm), - FFI (recent change from Doug will be here soon) and OsProcess (I just don not try it yet but I didn't look at it). I think the VM is stable enough to be used. I will move the infrastructure to the file server today, the last raspberry pi VM should work. It will be fixed during the day. On 30 Apr 2014, at 12:31, Goubier Thierry <thierry.goubier(a)cea.fr> wrote: > > > Le 30/04/2014 11:58, jannik laval a Ã©crit : >> I have a Phratch that begin to work on RPi >> (https://ci.inria.fr/pharo-contribution/view/Phratch/job/Phratch-OneClick-RP…) >> So, you can probably use Pharo 3 > > Thanks. > > I'll start moving the infrastructure there then. > > Thierry > >> Now I have problems with FileSystem, I will ask in another thread. > >> Jannik >> >> -- >> >> ~~Jannik Laval~~ >> Ãcole des Mines de Douai >> Enseignant-chercheur >> http://www.jannik-laval.eu >> http://www.phratch.com >> http://car.mines-douai.fr/ >> > > -- > Thierry Goubier > CEA list > Laboratoire des Fondations des SystÃ¨mes Temps RÃ©el EmbarquÃ©s > 91191 Gif sur Yvette Cedex > France > Phone/Fax: +33 (0) 1 69 08 32 92 / 83 95 > Best Regards Jean Baptiste Arnaud jbaptiste.arnaud(a)gmail.com

April 30, 2014

[pharo-project/pharo-core] 716f48: 30846

by GitHub

Branch: refs/heads/3.0 Home: https://github.com/pharo-project/pharo-core Commit: 716f48dcd77dce7178bf76b381e5a75e192c8aec https://github.com/pharo-project/pharo-core/commit/716f48dcd77dce7178bf76b3… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2014-04-30 (Wed, 30 Apr 2014) Changed paths: M Athens-Cairo.package/AthensCairoSurface.class/README.md M Athens-Cairo.package/AthensCairoSurface.class/class/instance creation/extent_format_.st M Athens-Cairo.package/AthensCairoSurface.class/class/instance creation/width_height_.st M Athens-Cairo.package/AthensCairoSurface.class/instance/accessing/height.st A Athens-Cairo.package/AthensCairoSurface.class/instance/private/privateHeight.st A ScriptLoader30.package/ScriptLoader.class/instance/pharo - scripts/script108.st A ScriptLoader30.package/ScriptLoader.class/instance/pharo - updates/update30846.st M ScriptLoader30.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st Log Message: ----------- 30846 13236 Fix 1 extra height for Cairo surface https://pharo.fogbugz.com/f/cases/13236 http://files.pharo.org/image/30/30846.zip

April 30, 2014

[pharo-project/pharo-core]

by GitHub

Branch: refs/tags/30846 Home: https://github.com/pharo-project/pharo-core

April 30, 2014

Re: [Pharo-dev] Pharo on RPi

by Goubier Thierry

Le 30/04/2014 11:58, jannik laval a Ã©crit : > I have a Phratch that begin to work on RPi > (https://ci.inria.fr/pharo-contribution/view/Phratch/job/Phratch-OneClick-RP…) > So, you can probably use Pharo 3 Thanks. I'll start moving the infrastructure there then. Thierry > Now I have problems with FileSystem, I will ask in another thread. > Jannik > > -- > > ~~Jannik Laval~~ > Ãcole des Mines de Douai > Enseignant-chercheur > http://www.jannik-laval.eu > http://www.phratch.com > http://car.mines-douai.fr/ > -- Thierry Goubier CEA list Laboratoire des Fondations des SystÃ¨mes Temps RÃ©el EmbarquÃ©s 91191 Gif sur Yvette Cedex France Phone/Fax: +33 (0) 1 69 08 32 92 / 83 95

April 30, 2014