September 2009 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] Status of Alien FFI

by StÃ©phane Ducasse

ok what is its license? Stef > what is the cairoPackage? >> For pharo 1.1 I would like to see Rome cleaned and loadable/ >> integrated >> in pharo. > > It's a port of Travis Griggs' package from VisualWorks -- a fairly > direct mapping of Cairo objects into Smalltalk. I posted it on > SqueakSource just a couple of days ago: > > http://www.squeaksource.com/CairoGraphics.html > > I have been using it for our VisualWorks web apps for quite a while > and wanted to bring it with me. Plus I really need portability > between Pharo and GLASS. Not that I couldn't do that with Rome, but > this seemed like an easier path for me. > > -- > Ken Treis > Miriam Technologies, Inc. > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Sept. 16, 2009

Re: [Pharo-project] getting rid of these boring questions and popup

by StÃ©phane Ducasse

hi guys http://code.google.com/p/pharo/issues/detail?id=1224 Now there is the possibility to not be warned for | a | a + 1 When you compile and also removing unused variable Parser doNotWarnUser Parser WarnUser compiler-sd.117 in the inbox I would prefer that somebody have a look before I push that in the stream Stef On Sep 14, 2009, at 4:40 PM, Schwab,Wilhelm K wrote: > Stef, > > Sounds great - thanks! > > Bill > > > > > -----Original Message----- > From: pharo-project-bounces(a)lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr > ] On Behalf Of StÃ©phane Ducasse > Sent: Monday, September 14, 2009 9:30 AM > To: Pharo-project(a)lists.gforge.inria.fr > Subject: Re: [Pharo-project] getting rid of these boring questions > and popup > > bill for now I will cherrypick the removal of the two boring one. > for the rest we will see. > > Stef > > On Sep 14, 2009, at 3:55 PM, Schwab,Wilhelm K wrote: > >> Hernan, Stef >> >> I still would perfer to just ses the syntax error; perhaps it is just >> pop-up burnout, but I find them annoying, but not so much so that I >> would object if Stef wants to integrate this as-is. >> >> I vaugely recall that the changes include removing notifieres, which >> really steps on my toes. As is always my position on such things, I >> do not care if *you* skip them, but I do not want them removed from >> my >> image. Taking some small action to enable them is fine, but I ask >> the >> benevolent dictators to not allow them to be removed. >> >> Bill >> >> >> >> From: pharo-project-bounces(a)lists.gforge.inria.fr >> [mailto:pharo-project-bounces@lists.gforge.inria.fr >> ] On Behalf Of Hernan Wilkinson >> Sent: Monday, September 14, 2009 6:35 AM >> To: Pharo-project(a)lists.gforge.inria.fr >> Subject: Re: [Pharo-project] getting rid of these boring questions >> and >> popup >> >> I think there are two pop ups that should stay because they help TDD: >> 1) When the variable is not defined and you want to define it as >> instance variable (it is very common to do that) >> 2) When the class does not exists and you want to create it from >> there. >> >> The other (message not exist, etc) should not be there. >> BTW, I did that on the TDDFacilities package. It is on SqueakSource: >> >> MCHttpRepository >> location: 'http://www.squeaksource.com/TDDFacilities' >> user: '' >> password: '' >> >> Bye, >> Hernan. >> >> On Sun, Sep 13, 2009 at 12:41 PM, StÃ©phane Ducasse >> <stephane.ducasse(a)inria.fr >>> wrote: >> Guys >> >> you may not have noticed it but I would love to get the code to >> remove >> these boring popups :) >> >> Stef >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Sept. 16, 2009

Re: [Pharo-project] Status of Alien FFI

by Mariano Martinez Peck

On Wed, Sep 16, 2009 at 6:17 PM, Ken Treis <ken(a)miriamtech.com> wrote: > > On Sep 16, 2009, at 12:02 PM, Douglas Brebner wrote: > > > One minor point is that whether integers and longs are different > > depends > > on the platforms data model. Under MS Win64, integers and long > > integers > > are both 32bit, while on most unixes integers are 32bit while long > > ints > > are 64bit. (LLP64 and LP64 models respectively) > > > > I don't know if this is important though. > > Good point. All of my platforms are LP64 (Mac OS X and Linux x86-64), > and my main objective at present is to get this working for an > application I'm committed to build, so I was ignoring those sorts of > cross-platform details. > +1. Please take into consideration to make Alien cross platform!!! Just as FFI is. > > Perhaps there would need to be new primitives for the basic size of > each relevant C type? I'm anxious to hear what Eliot might have to say > about this since he's got about 2000x more experience with this than I > do. > > -- > Ken Treis > Miriam Technologies, Inc. > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Sept. 16, 2009

Re: [Pharo-project] Fwd: Universes? or Metacello meta repository

by Dale Henrichs

When defining project references in Metacello, you can use a #>= operator which basically says that later versions are okay - this makes it possible for MyApp to specify AppA v1 but be able to use AppA v3 if it is already loaded... The problem of conflicting requirements isn't solved but Metacello doesn't _force_ one to use a particular version unless you want it to (using #= as the operator forces that version to be loaded)... Dale ----- "StÃ©phane Ducasse" <stephane.ducasse(a)inria.fr> wrote: | I remembered that. Now I was wondering about the following | | if we can tag a config we get in essence an Universe: a set of | packages wrking with a given tag. | But this is not quite the same. | | One of the problem that universes solved is that if | | MyApp requires | AppA v1 | | YourApp requires | AppA v3 | | I can load MyApp and YourApp separately but together thy may conflict | | or do not work | | Now universe forces me and you to choose when we publish because there | | was only one AppA | the AppA for the current Universe. | | Stef | | On Sep 16, 2009, at 6:42 PM, Dale Henrichs wrote: | | > Stef, | > | > Under Metacello, when you a release a version, the complete list of | | > Monticello files are recorded with the version (including load order | | > dependencies). | > | > So Metacello is designed to make it possible to load old versions of | | > projects into new images. | > | > It is also possible to record the versions of all of the projects | > that you are using, so you can record the exact version of Seaside, | | > Magritte and Pier you are using at a particular point in time, and | | > then you load that exact configuration into a different image at any | | > time in the future. | > | > Dale | > ----- "StÃ©phane Ducasse" <stephane.ducasse(a)inria.fr> wrote: | > | > | Ok but for pharo1.0 it would be nice to have it :) | > | then after we plug metacello underneath | > | | > | Doru with metacello will we be able to say | > | I want to load in the past the version of moose which worked | with | > | pharo1.0 | > | even if now I'm working on pharo 3.2 (the real future :)) | > | | > | Stef | > | On Sep 16, 2009, at 1:08 PM, Damien Cassou wrote: | > | | > | > On Wed, Sep 16, 2009 at 11:38 AM, Tudor Girba | <girba(a)iam.unibe.ch> | > | | > | > wrote: | > | >> I believe Metacello is a very nice piece of work and it should | be | > | a | > | >> very strong contender for managing releases. The ui tools are | not | > | >> quite there yet, but it works very nicely for allowing someone | to | > | >> specify the exact configuration to be loaded. | > | > | > | > I agree. Universes is cool but: | > | > | > | > - it requires a dedicated server and only few people installed | one | > | | > | > already | > | > - it only allows one administrator per package description | > | > - the interface is well... not very nice :-) | > | > - we would need to create a new universe from scratch | > | > | > | > -- | > | > Damien Cassou | > | > http://damiencassou.seasidehosting.st | > | > | > | > "Lambdas are relegated to relative obscurity until Java makes | them | > | > popular by not having them." James Iry | > | > | > | > _______________________________________________ | > | > Pharo-project mailing list | > | > Pharo-project(a)lists.gforge.inria.fr | > | > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo- | > project | > | | > | | > | _______________________________________________ | > | Pharo-project mailing list | > | Pharo-project(a)lists.gforge.inria.fr | > | | http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project | > | > _______________________________________________ | > Pharo-project mailing list | > Pharo-project(a)lists.gforge.inria.fr | > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Sept. 16, 2009

Re: [Pharo-project] Status of Alien FFI

by Ken Treis

On Sep 16, 2009, at 12:02 PM, Douglas Brebner wrote: > One minor point is that whether integers and longs are different > depends > on the platforms data model. Under MS Win64, integers and long > integers > are both 32bit, while on most unixes integers are 32bit while long > ints > are 64bit. (LLP64 and LP64 models respectively) > > I don't know if this is important though. Good point. All of my platforms are LP64 (Mac OS X and Linux x86-64), and my main objective at present is to get this working for an application I'm committed to build, so I was ignoring those sorts of cross-platform details. Perhaps there would need to be new primitives for the basic size of each relevant C type? I'm anxious to hear what Eliot might have to say about this since he's got about 2000x more experience with this than I do. -- Ken Treis Miriam Technologies, Inc.

Sept. 16, 2009

Re: [Pharo-project] Status of Alien FFI

by Ken Treis

On Sep 16, 2009, at 11:54 AM, StÃ©phane Ducasse wrote: > what is the cairoPackage? > For pharo 1.1 I would like to see Rome cleaned and loadable/integrated > in pharo. It's a port of Travis Griggs' package from VisualWorks -- a fairly direct mapping of Cairo objects into Smalltalk. I posted it on SqueakSource just a couple of days ago: http://www.squeaksource.com/CairoGraphics.html I have been using it for our VisualWorks web apps for quite a while and wanted to bring it with me. Plus I really need portability between Pharo and GLASS. Not that I couldn't do that with Rome, but this seemed like an easier path for me. -- Ken Treis Miriam Technologies, Inc.

Sept. 16, 2009

Re: [Pharo-project] Status of Alien FFI

by Douglas Brebner

Ken Treis wrote: > > * I'm creating a partial Alien library for GemStone so that I can use > the CairoGraphics package in both Pharo and GLASS. But on x86-64, > there there's a size difference between a pointer/long and an integer. > It'd be nice to have some more explicit APIs on Alien, so I could say > "Alien newCInteger" or "Alien newCLong" and have the platform return > me the proper size Alien. Even without the platform size differences, > it seems awkward to use "Alien newC: 4" everywhere I want an integer, > "Alien newC: 8" where I want a double, etc. > > * Similarly, I'd like an API on AlienLibrary that distinguishes > between integers and longs. In the CairoGraphics package I've added > some methods to this effect: One minor point is that whether integers and longs are different depends on the platforms data model. Under MS Win64, integers and long integers are both 32bit, while on most unixes integers are 32bit while long ints are 64bit. (LLP64 and LP64 models respectively) I don't know if this is important though.

Sept. 16, 2009

Re: [Pharo-project] Status of Alien FFI

by StÃ©phane Ducasse

I will let eliot comment on that because I'm alien newbie. We cleaned it so that people can use it but > >> it is correct that alien touches the parser? >> The declarations are not pragmas compliant. > > Yes -- there's a hack in there that allows an error code variable to > be passed in the <primitive> pragma where otherwise the parser would > expect a literal. > >> Of course your suggestion makes sense. >> When marcus is back in europe I will check the status of the >> new handwritten parser because it would be good to use it. > > > Thanks Stef. I've got some other ideas for Alien; is this list the > best place to discuss those? Specifically: > > * AlienLibrary shouldn't do its cleanup at shutdown, it should do it > at image startup instead. That way a simple image save won't > invalidate all of my external references. > > * I'm creating a partial Alien library for GemStone so that I can > use the CairoGraphics package in both Pharo and GLASS. what is the cairoPackage? For pharo 1.1 I would like to see Rome cleaned and loadable/integrated in pharo. > But on x86-64, there there's a size difference between a pointer/ > long and an integer. It'd be nice to have some more explicit APIs on > Alien, so I could say "Alien newCInteger" or "Alien newCLong" and > have the platform return me the proper size Alien. Even without the > platform size differences, it seems awkward to use "Alien newC: 4" > everywhere I want an integer, "Alien newC: 8" where I want a double, > etc. > > * Similarly, I'd like an API on AlienLibrary that distinguishes > between integers and longs. In the CairoGraphics package I've added > some methods to this effect: > > CRLibrary > int: 'cairo_surface_write_to_png' with: handle with: string > address > > or > > patternHandle := CRLibrary pointer: 'cairo_pop_group' with: > handle. > > I like the way it reads. And even though on IA32 they both use the > same 4-byte primitive, on x86-64 I could have pointers return an 8- > byte Alien and ints return a 4-byte primitive. > > * Same story with the basic data accessors like (un)signedLongAt: -- > I'd want to add something like (un)signedIntAt et. al. > > Yes, I realize that some of this is overkill for IA32 only, but on > the other hand I think a couple of these intention-revealing changes > would make Alien client code prettier. > > Sorry to be so wordy. I'd be glad to do all of the Smalltalk-level > coding on this -- much of it is done already in my image -- but I > thought I'd better ask the maintainer(s) first and this list is the > best forum I've found for Alien issues. > > -- > Ken Treis > Miriam Technologies, Inc. > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Sept. 16, 2009

Re: [Pharo-project] Status of Alien FFI

by Ken Treis

On Sep 16, 2009, at 11:14 AM, StÃ©phane Ducasse wrote: > it is correct that alien touches the parser? > The declarations are not pragmas compliant. Yes -- there's a hack in there that allows an error code variable to be passed in the <primitive> pragma where otherwise the parser would expect a literal. > Of course your suggestion makes sense. > When marcus is back in europe I will check the status of the > new handwritten parser because it would be good to use it. Thanks Stef. I've got some other ideas for Alien; is this list the best place to discuss those? Specifically: * AlienLibrary shouldn't do its cleanup at shutdown, it should do it at image startup instead. That way a simple image save won't invalidate all of my external references. * I'm creating a partial Alien library for GemStone so that I can use the CairoGraphics package in both Pharo and GLASS. But on x86-64, there there's a size difference between a pointer/long and an integer. It'd be nice to have some more explicit APIs on Alien, so I could say "Alien newCInteger" or "Alien newCLong" and have the platform return me the proper size Alien. Even without the platform size differences, it seems awkward to use "Alien newC: 4" everywhere I want an integer, "Alien newC: 8" where I want a double, etc. * Similarly, I'd like an API on AlienLibrary that distinguishes between integers and longs. In the CairoGraphics package I've added some methods to this effect: CRLibrary int: 'cairo_surface_write_to_png' with: handle with: string address or patternHandle := CRLibrary pointer: 'cairo_pop_group' with: handle. I like the way it reads. And even though on IA32 they both use the same 4-byte primitive, on x86-64 I could have pointers return an 8- byte Alien and ints return a 4-byte primitive. * Same story with the basic data accessors like (un)signedLongAt: -- I'd want to add something like (un)signedIntAt et. al. Yes, I realize that some of this is overkill for IA32 only, but on the other hand I think a couple of these intention-revealing changes would make Alien client code prettier. Sorry to be so wordy. I'd be glad to do all of the Smalltalk-level coding on this -- much of it is done already in my image -- but I thought I'd better ask the maintainer(s) first and this list is the best forum I've found for Alien issues. -- Ken Treis Miriam Technologies, Inc.

Sept. 16, 2009

Re: [Pharo-project] Author name prompt window is too big

by StÃ©phane Ducasse

Excellent Soon in your update :) Stef On Sep 16, 2009, at 7:41 PM, Miguel Enrique CobÃ¡ Martinez wrote: > El miÃ©, 16-09-2009 a las 16:15 +0200, Oscar Nierstrasz escribiÃ³: >> Today I was giving a Pharo demo, using a slightly larger than >> standard >> font. >> >> When I tried to commit a change, the prompt for my user name was >> bigger than the available screen space on my laptop. Luckily I could >> still type, though I could not see what I was typing. >> >> Can we please modify Author>>messagePrompt to use a *short* message? >> The existing one is ridiculously large. > > Issue number: > > http://code.google.com/p/pharo/issues/detail?id=1223 > > Fixed now: > > Fixed on System-Support-MiguelCoba.88.mcz on PharoInbox > > -- > Miguel CobÃ¡ > http://miguel.leugim.com.mx > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Sept. 16, 2009