- Pharo-dev - lists.pharo.org

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

Re: [Pharo-project] Website screenshots

by StÃ©phane Ducasse

Mike I do not know if you can edit the site because adrian is on holiday and I do not remember :) On Sep 16, 2009, at 7:09 PM, Gary Chambers wrote: > I guess the IDE screenshot could do with updating... old-stlye > buttons! > Just mention because linked from Planet Squeak (re: Facelifiting > Smalltalk). > > Might be nice with #showTextEditingState preference enabled now too... > > Regards, Gary > _______________________________________________ > 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 StÃ©phane Ducasse

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] Fwd: Universes? or Metacello meta repository

by StÃ©phane Ducasse

good to know. My questioning is more about the infrastructure that we will have to put in place to manage external project to get a kind of universe for pharo based on metacello. Because at the end, I thought that the proposal of damien was that external projects ie Sixx, Ob,.... could be managed used metacello but may be the author does not want so we will have to provide metacello projects for those. Stef On Sep 16, 2009, at 6:35 PM, Dale Henrichs wrote: > Stef, > > I think that the core of Metacello is very solid. Doru is using it > for Moose (a large project) and I am using it for GLASS managing 20 > some individual projects like Pier, Seaside 2.8 and Magritte. I am > working on a Metacello configuration for Seaside 3.0 - almost 70 > packages and around 30 sub projects ... > > The API (DSL actually) and UI is still under development. > > The API is usable but in a few places is probably more complex than > it needs to be. The UI is virtually non-existent, but that is being > worked on, right Doru:). > > So far I've been able to maintain backwards compatibility for the > API as Doru and I have moved the API forward, but until we've > finalized things there's always the chance that we'd need to 'break' > something. > > If we have a good UI, then the changes in the API can be hidden to a > large extent... > > In the end it is probably prudent to wait a bit before going with > widespread usage of Metacello within Pharo and use it only in the > places with particularly difficult configuration issues... > > Within the next month I will be facing a similar decision - I am > pushing hard on Seaside 3.0 on top of GemStone 2.4 and Metacello is > an integral part of the effort. I will need to decide whether the > API is mature enough at that time to push out the GLASS release. > > Dale > > ----- "StÃ©phane Ducasse" <stephane.ducasse(a)inria.fr> wrote: > > | Hi > | > | I value the idea that when we look for a software (for example SIXX) > | we can find a version that is working. In the past we used Universes > | and > | if was successful. > | We cannot not have squeakmap and universe at the same time. > | I discussed with damien briefly about that and he told me that we > coud > | > | have > | a metacello alternative. > | Now I wonder if for pharo 1.0 it makes sense. > | May be having a nice Universe for pharo would be good and important. > | > | Dale what do you think? > | Do you see metacello working in the story (may be for 1.1)? > | 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

Sept. 16, 2009

Re: [Pharo-project] Status of Alien FFI

by StÃ©phane Ducasse

Hi ken it is correct that alien touches the parser? The declarations are not pragmas compliant. 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. Stef On Sep 16, 2009, at 5:36 PM, Ken Treis wrote: > On Sep 16, 2009, at 1:06 AM, Johan Brichau wrote: > >> I separated the extensions to the Parser (necessary to load the >> primitive methods) into a separate package Alien-Prereqs. >> If you load Alien-Prereqs before Alien-Core, it will work. > > > Thanks Johan, that's good news here. I appreciate it. > > Given that Alien requires modifications to the core parser, and that > the Alien-modified parser is backwards-compatible with the base > parser... is there any chance we can get the Alien modifications > into the base? Without that, Pharo software updates that touch > parser code will end up reverting the code in Alien-Prereqs, right? > > -- > 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] Author name prompt window is too big

by Miguel Enrique CobÃ¡ Martinez

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

Sept. 16, 2009