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

Re: [Pharo-project] No win or macos build for Nativeboost in Jeckins

by Camillo Bruni

Sadly our infrastructure is currently failing :) but we're working on it. Igor is currently fixing the windows build :) On 2012-10-02, at 11:09, dimitris chloupis <thekilon(a)yahoo.co.uk> wrote: > I am trying to get a build for Nativeboost Cogvm for the past several weeks and it seems no build is available for win32 or macos. > > > https://ci.lille.inria.fr/pharo/job/NativeBoost-Cog-VM/ > > Any idea why this happens and when it will be resolved ? thanks. > > > I am also interested in using Athens for a new GUI api that I am making.

Oct. 2, 2012

[Pharo-project] No win or macos build for Nativeboost in Jeckins

by dimitris chloupis

I am trying to get a build for Nativeboost Cogvm for the past several weeks and it seems no build is available for win32 or macos. https://ci.lille.inria.fr/pharo/job/NativeBoost-Cog-VM/ Any idea why this happens and when it will be resolved ? thanks. I am also interested in using Athens for a new GUI api that I am making.Â

Oct. 2, 2012

[Pharo-project] [update 2.0] #20318

by Marcus Denker

20318 ----- Issue 6751: Use gzip compression for most transferred files http://code.google.com/p/pharo/issues/detail?id=6751 Issue 6729: Array SubscriptOutOfBounds: in PluggableListMorph http://code.google.com/p/pharo/issues/detail?id=6729 -- Marcus Denker -- http://marcusdenker.de

Oct. 2, 2012

Re: [Pharo-project] rmod is down -> fuel for squeak?

by Mariano Martinez Peck

On Tue, Oct 2, 2012 at 6:48 AM, Max Leske <maxleske(a)gmail.com> wrote: > No, this time it's not for seaside hosting. It's another application that > we cannot port to Pharo at the moment. > > Ok. What you should try to do (since I guess Metacello does not work there) is to manually load this (the order is important): ConfigurationOfFuel project stableVersion record a MetacelloNullRecordingMCSpecLoader(linear load : linear load : 1.8 [ConfigurationOfFuel] load : Fuel-MartinDias.685 load : FuelTests-MartinDias.267 load : FuelCompatibilityBeforePharo20-MartinDias.4 load : FuelCompatibilityBeforePharo14-MartinDias.3 load : FuelCompatibilityBeforePharo13-MarianoMartinezPeck.3 load : FuelCompatibilityBeforePharo12-MartinDias.8 load : FuelCompatibilityForSqueak-MMP.4 load : FuelTestsCompatibilityForSqueak) and try to see what happens :) > Max > > > On 01.10.2012, at 23:07, Mariano Martinez Peck <marianopeck(a)gmail.com> > wrote: > > > > On Mon, Oct 1, 2012 at 11:04 PM, Max Leske <maxleske(a)gmail.com> wrote: > >> Thanks Mariano. >> >> I can confirm that it works out of the box in Squeak 4.3. >> >> > :) > > >> I have a 3.9 image thoughâ¦ :) >> >> > I'll let you know if I get it running on there >> > > Let me know if I can help. If you make it work, we can do a compatibility > package and put it in ConfigurationOfFUel so that it loads automatically in > Squeak 3.9. > > >> (might be simpler to use a newer image though). >> >> > Well, it looks this is for seasidehosting? in either case, why not > updating to Pharo? because of the custom network primitives you have? > > >> >> On 01.10.2012, at 22:51, Mariano Martinez Peck <marianopeck(a)gmail.com> >> wrote: >> >> >> >> On Mon, Oct 1, 2012 at 10:44 PM, Max Leske <maxleske(a)gmail.com> wrote: >> >>> I wanted some info on Fuel but the rmod page is downâ¦ >>> >>> Anyways, I read that Mariano got Fuel running on Squeak. Is there an >>> official version for Squeak? >>> >>> >> Hi Max. It should just work. The ConfigurationOfFuel should automatically >> load the needed compatibility packages. >> I tried in 4.3 and 4.1 (if I remember correctly). >> >> >> >> -- >> Mariano >> http://marianopeck.wordpress.com >> >> >> > > > -- > Mariano > http://marianopeck.wordpress.com > > > -- Mariano http://marianopeck.wordpress.com

Oct. 2, 2012

Re: [Pharo-project] [Another sad day] a nice example of the mess with json in FileTree

by Henrik Sperre Johansen

On 01.10.2012 22:01, StÃ©phane Ducasse wrote: > No it was quite ok :) > Working at home, good music, view on my garden, flower and butterfly. > > Stef Sounds like a Halloween trailer. Everything is peaceful and idyllic, then; JSON! ;) Cheers, Henry

Oct. 2, 2012

Re: [Pharo-project] [Another sad day] a nice example of the mess with json in FileTree

by Tudor Girba

Great. I guess this is what happens if one misses too many ESUGs :). Thanks, Doru On Mon, Oct 1, 2012 at 11:44 PM, Dale Henrichs <dhenrich(a)vmware.com> wrote: > > ----- Original Message ----- > | From: "Tudor Girba" <tudor(a)tudorgirba.com> > | To: Pharo-project(a)lists.gforge.inria.fr > | Sent: Monday, October 1, 2012 1:22:41 PM > | Subject: Re: [Pharo-project] [Another sad day] a nice example of the mess with json in FileTree > | > | Hi, > | > | I like the project, but I second the concerns of Stef. But, as I > | understand, there seems to be consensus in this regard. > | > | One thing I still do not quite understand why we keep on having > | version information inside the structural information. Why is it not > | enough to let it only be the responsibility of the versioning system? > | > | As it is now, we are versioning the versions. > | > | If I understand correctly, the only reason is to accommodate legacy > | version information. If this is the case, I guess a possibility would > | be to just simulate this information in an initial commit, if we need > | it at all. > | > | Do I miss something? > > Doru, > > The only point that you are missing is that the method timestamps are being included in the files themselves as a temporary measure until we have better git integration ... > > The original version of FileTree didn't have timestamps and for a short period I added them back in and then removed them again until this conversation occurred[3]. At that point it seemed like a good idea at the time to preserve the timestamps until they could be properly replaced by the underlying versioning system ... > > Cami Bruni and Max Leske are working on solving the git integration problem[1] ... as soon as we have good integration we'll be nuking the time stamp information from FileTree... > > Frank Shearar is working on an implementation of "the initial commit"[2] that allows one to duplicate the full Monticello history of a project in a git repository... > > Dale > > [1] https://github.com/dalehenrich/FSGit > [2] http://www.lshift.net/blog/2012/08/20/monticello-git > [3] http://forum.world.st/preserving-version-creator-timestamp-in-filetree-td46… > -- www.tudorgirba.com "Every thing has its own flow"

Oct. 2, 2012

Re: [Pharo-project] rmod is down -> fuel for squeak?

by Max Leske

No, this time it's not for seaside hosting. It's another application that we cannot port to Pharo at the moment. Max On 01.10.2012, at 23:07, Mariano Martinez Peck <marianopeck(a)gmail.com> wrote: > > > On Mon, Oct 1, 2012 at 11:04 PM, Max Leske <maxleske(a)gmail.com> wrote: > Thanks Mariano. > > I can confirm that it works out of the box in Squeak 4.3. > > > :) > > I have a 3.9 image thoughâ¦ :) > > I'll let you know if I get it running on there > > Let me know if I can help. If you make it work, we can do a compatibility package and put it in ConfigurationOfFUel so that it loads automatically in Squeak 3.9. > > (might be simpler to use a newer image though). > > > Well, it looks this is for seasidehosting? in either case, why not updating to Pharo? because of the custom network primitives you have? > > > On 01.10.2012, at 22:51, Mariano Martinez Peck <marianopeck(a)gmail.com> wrote: > >> >> >> On Mon, Oct 1, 2012 at 10:44 PM, Max Leske <maxleske(a)gmail.com> wrote: >> I wanted some info on Fuel but the rmod page is downâ¦ >> >> Anyways, I read that Mariano got Fuel running on Squeak. Is there an official version for Squeak? >> >> >> Hi Max. It should just work. The ConfigurationOfFuel should automatically load the needed compatibility packages. >> I tried in 4.3 and 4.1 (if I remember correctly). >> >> >> >> -- >> Mariano >> http://marianopeck.wordpress.com >> > > > > > -- > Mariano > http://marianopeck.wordpress.com >

Oct. 2, 2012

Re: [Pharo-project] [Another sad day] a nice example of the mess with json in FileTree

by H. Hirzel

On 10/1/12, phil(a)highoctane.be <phil(a)highoctane.be> wrote: > Just a note that may be of interest. > > I moved off Git and into Fossil. Check it out, it may actually be easier > for us to work with since everything lives in a single Sqlite database. No > more files everywhere. The author of Fossil is the author of Sqlite. > Thank you for reminding me of this. > The whole Tcl/Tk source moved into that as well. > For me it looks like coherent with the Smalltalk idea of an image and > metadata access that is easy. Not really easy to do with a bunch of files. > > And the commands are pretty much compatible. > > As an added benefit, you get a free issue tracker and wiki built in to > document all of the package. > http://fossil-scm.org/fossil/doc/trunk/www/webui.wiki > Phil > > 2012/10/1 Dale Henrichs <dhenrich(a)vmware.com> > >> Stef, >> >> I forgot to share with you that at this last ESUG we (Jan Vrany, Martin >> Kobetic and myself) agreed that the next version of Filetree will use >> .ston >> files instead of .json files. I am planning on writing a blog post on >> this...eventually. >> >> The Smalltalk/X implementation (Jan Vrany) is using .ston files and >> version 2.0 of FileTree will using .ston files and I will be working on >> version 2.0 soon. Jan is planning on using Metacello with Smaltalk/X so >> I'll need to implement version 2.0 of FileTree to share code with him... >> >> .json files are on the way out! >> >> Dale >> ----- Original Message ----- >> | From: "StÃ©phane Ducasse" <stephane.ducasse(a)inria.fr> >> | To: "Pharo-project(a)lists.gforge.inria.fr Development" < >> Pharo-project(a)lists.gforge.inria.fr> >> | Sent: Monday, October 1, 2012 10:00:47 AM >> | Subject: [Pharo-project] [Another sad day] a nice example of the mess >> with json in FileTree >> | >> | Hi guys >> | >> | I was browsing (at least trying) to have a look at mist >> | >> https://github.com/martinmcclure/mist/commit/b3103bd30be11dd8063aa9ce212a36… >> | >> | and this is so nice to see json code in the middle of Smalltalk >> | methods. Look for class definitions there are >> | great. Yes it will help newcomers to jump into Smalltalk. So great. >> | We avoided the XML crap as in VW but apparently we will not avoid the >> | shit of JSON. >> | >> | May be this is the clear indication that we should all stop to code >> | in Smalltalk (a dead language anyway) and all switch to Javascript >> | in a plain happiness. Have a look this is great to read class >> | definitions and method categories like that. I love FileTree. I love >> | JSON. >> | >> | What is terribly fun is that JSON could be good if we would not have >> | a declarative syntax for exactly the same but >> | new is always better. So long life to FileTree and JSON. >> | >> | Stef >> | PS: Of course you can all piss on me, do it if this helps you. >> | Now tell me that I do not have to use GitHub to browse code and all >> | kind of nice argumentsâ¦ >> | while at the same time, people are telling me the inverse. >> | >> | Yes I can stick with my old crappy browser and we will explain to our >> | students that we were not able to use >> | the syntax of our language to express nicely the same. >> | >> | PSPS: so do not ask me any help and support for such idea. >> | >> >> >

Oct. 1, 2012

Re: [Pharo-project] Metacello bleedingEdge question

by Dale Henrichs

Not sure whether or not these are doable with Slime, but they are good ideas Dale ----- Original Message ----- | From: "Alexandre Bergel" <alexandre.bergel(a)me.com> | To: Pharo-project(a)lists.gforge.inria.fr | Sent: Monday, October 1, 2012 1:30:44 PM | Subject: Re: [Pharo-project] Metacello bleedingEdge question | | > I was thinking in terms of Slime for Seaside. | > One PhD student is working on rule and I was thinking that it would | > be fun to have a kind of | > Metacello checker. | > do you have some rule of thumb where to look for potential | > problems? | > Because it can be a fun experience. | | I had this idea of a checker for Metacello (that can be used with | Versionner before committing), but never got the traction to do it. | Some rules: | - two packages in a graph of dependencies may rely on a different | version of a third package | - identifying cycles in packages | - very important: checking whether the dependencies defined in | Metacello matches with the actual source code. Said in other | words, do I miss some dependencies in a configuration? | | Cheers, | Alexandre | | -- | _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: | Alexandre Bergel http://www.bergel.eu | ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. | | | | |

Oct. 1, 2012

Re: [Pharo-project] [Another sad day] a nice example of the mess with json in FileTree

by Dale Henrichs

----- Original Message ----- | From: "Tudor Girba" <tudor(a)tudorgirba.com> | To: Pharo-project(a)lists.gforge.inria.fr | Sent: Monday, October 1, 2012 1:22:41 PM | Subject: Re: [Pharo-project] [Another sad day] a nice example of the mess with json in FileTree | | Hi, | | I like the project, but I second the concerns of Stef. But, as I | understand, there seems to be consensus in this regard. | | One thing I still do not quite understand why we keep on having | version information inside the structural information. Why is it not | enough to let it only be the responsibility of the versioning system? | | As it is now, we are versioning the versions. | | If I understand correctly, the only reason is to accommodate legacy | version information. If this is the case, I guess a possibility would | be to just simulate this information in an initial commit, if we need | it at all. | | Do I miss something? Doru, The only point that you are missing is that the method timestamps are being included in the files themselves as a temporary measure until we have better git integration ... The original version of FileTree didn't have timestamps and for a short period I added them back in and then removed them again until this conversation occurred[3]. At that point it seemed like a good idea at the time to preserve the timestamps until they could be properly replaced by the underlying versioning system ... Cami Bruni and Max Leske are working on solving the git integration problem[1] ... as soon as we have good integration we'll be nuking the time stamp information from FileTree... Frank Shearar is working on an implementation of "the initial commit"[2] that allows one to duplicate the full Monticello history of a project in a git repository... Dale [1] https://github.com/dalehenrich/FSGit [2] http://www.lshift.net/blog/2012/08/20/monticello-git [3] http://forum.world.st/preserving-version-creator-timestamp-in-filetree-td46…

Oct. 1, 2012