- Pharo-dev - lists.pharo.org

Re: [Pharo-project] Alien on Pharo 1.2 on Mac

by Luc Fabresse

Hi All, I pushed a new version of Alien in the the Alien repo ( http://www.squeaksource.com/Alien) (thanks to John who granted us access). This version (#64) makes the 40 Alien tests green in Pharo 1.2-12049 . Since the ConfigurationOfAlien has not been changed yet, you can load it using: Gofer new url: 'http://www.squeaksource.com/Alien' ; package: 'ConfigurationOfAlien'; load. (ConfigurationOfAlien project version: '1.0-baseline') load: #('Core' 'Tests' 'LibC') Luc On Tue, Jul 6, 2010 at 9:13 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>wrote: > you do not have access to the alien repository? > can you ask john to gve you access to it? > > On Jul 6, 2010, at 3:41 PM, Luc Fabresse wrote: > > > Hi all, > > > > We provide a usable version of Alien to Pharo 1.2 (all tests green on > OSX). > > We committed the corrected package on the Ocean squeaksource repository : > http://squeaksource.com/Ocean > > (Alien-Core-LucFabresse.64.mcz) > > > > We didn't look in details to the method > SystemDictionary>>recreateSpecialObjectsArray introduced by Alien-Core-63. > > It is now unsed because Smalltalk points to a SmalltalkImage. > > This need to be checked before possibly removal. > > > > Another point would be to update the metacello configuration > ConfigurationOfAlien. > > > > Luc and Noury > > > > _______________________________________________ > > 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 >

July 13, 2010

[Pharo-project] please sign the license agreement

by StÃ©phane Ducasse

Hi all even if the simple fact that you submit code to the bug tracker or to the inbox means that you release your code under MIT for pharo, please take the license agreement, fill it up and send it to us. We got burn in the past with such problem http://code.google.com/p/pharo/wiki/LicenseAgreement Stef

July 13, 2010

Re: [Pharo-project] Optimize Pharo for slow horse

by Mariano Martinez Peck

Hilarie: first question, do you want to make faster what? The development there or the deploy of a particular application? On Tue, Jul 13, 2010 at 9:15 AM, Marcus Denker <marcus.denker(a)inria.fr>wrote: > > On Jul 12, 2010, at 10:45 PM, StÃ©phane Ducasse wrote: > > > instead of gradual typing I prefer the term pluggable types because it is > really clear what it means. > > > Pluggable types is differnt to "gradual typing". > > Pluggable types: Infrastucture to plug any type system (with infrastructure > to allow to infer > or or ignore non-annotated code). > > Gradual Types: One (kind of) Type System where type annotations are > optional: > > http://ecee.colorado.edu/~siek/gradualtyping.html<http://ecee.colorado.edu/%7Esiek/gradualtyping.html> > > > Marcus > > -- > Marcus Denker -- http://www.marcusdenker.de > INRIA Lille -- Nord Europe. Team RMoD. > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

July 13, 2010

Re: [Pharo-project] Optimize Pharo for slow horse

by Marcus Denker

On Jul 12, 2010, at 10:45 PM, StÃ©phane Ducasse wrote: > instead of gradual typing I prefer the term pluggable types because it is really clear what it means. > Pluggable types is differnt to "gradual typing". Pluggable types: Infrastucture to plug any type system (with infrastructure to allow to infer or or ignore non-annotated code). Gradual Types: One (kind of) Type System where type annotations are optional: http://ecee.colorado.edu/~siek/gradualtyping.html Marcus -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD.

July 13, 2010

[Pharo-project] Configuration how-to

by Hilaire Fernandes

Request for tips, suggestions and direction. What is the state of the art to: - load package - change preference setting (as the one seen in the Pharo setting tools. - remove unnecessary bits Hilaire

July 13, 2010

Re: [Pharo-project] [Vm-dev] Tracing on Linux

by Schwab,Wilhelm K

I think I found it. Trying to do this without callbacks in hand lead me to use a lot of C where I previously used block closures (that is not all bad, but it should not be necessary). As a result, I jam the data into a void pointer that is part of the library-designed function signature; with callbacks and closures, I simply shared the data inside the Smalltalk image and ignored the offending pointers. In this design, I put the points in a matrix that they treat as void* and therefore immediately indirected the pointer in the functions - big mistake, as they initially call the functions (for reasons I can't quite figure out) before the solver is configured and the data is known to the library. The pointer is therefore null and indirecting it was zapping me. A grander design might later reveal itself, but for now, it looks like a really sloppy part of the library. Bill -----Original Message----- From: pharo-project-bounces(a)lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Schwab,Wilhelm K Sent: Monday, July 12, 2010 4:34 PM To: Pharo-project(a)lists.gforge.inria.fr Subject: Re: [Pharo-project] [Vm-dev] Tracing on Linux Dave, I must respectfully disagree: the point is to see what Pharo "thinks" is happening in certain situations, so I need to see tracing info from it and from the library. Bill -----Original Message----- From: pharo-project-bounces(a)lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of David T. Lewis Sent: Monday, July 12, 2010 3:54 PM To: Pharo-project(a)lists.gforge.inria.fr Subject: Re: [Pharo-project] [Vm-dev] Tracing on Linux Using #stdOut from the image would not be useful for debugging a primitive or an FFI callout. Either use a real debugger (gdb et al) or put the fprintf someplace where you can see the parameters exactly as passed to the function. Dave On Mon, Jul 12, 2010 at 10:35:36AM -0400, Schwab,Wilhelm K wrote: > Dave, > > Any thoughts on mixing fprint()/fflush() in the .so with #stdOut in the image? I found #helloWorld, but some tinkering suggests that it is very sensitive to using #lf vs. #cr and/or does not like #flush. Does any of that sound familiar? > > Bill > > > > -----Original Message----- > From: pharo-project-bounces(a)lists.gforge.inria.fr > [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of > David T. Lewis > Sent: Monday, July 12, 2010 5:32 AM > To: Squeak Virtual Machine Development Discussion > Cc: Pharo-project(a)lists.gforge.inria.fr > Subject: Re: [Pharo-project] [Vm-dev] Tracing on Linux > > On Sun, Jul 11, 2010 at 05:30:35PM -0400, Schwab,Wilhelm K wrote: > > > > I am trying to track down a segmentation fault in calling into the Gnu Scientific Library. These are things that I had working under Windows+Dolphin and am now trying to do with Pharo and Linux. Offsets to structure elements and sizes of structures are possible snags, but the calls that are failing should be reasonably independent of such things: I call the relevant allocation method and pass along the pointer, so even if my interpretation of the structs is bogus, I would still expect the functions to succeed. That is all the more true of new functions that I am adding for testing purposes. > > > > The GSL functionality is split into two libraries, and the .so modules appear to be hobbled on Linux due to circular dependencies between them. A wrapper .so that is linked to both libraries seems to allow me to call "all" of the functions (the few I have tried to access) and gives a home for code of my own. > > > > I went so far as to compile some GSL sample code, and it does not crash. I further linked it to my wrapper library and it still works calling the GSL functions through the wrapper (or at least I *think* that's happening). I plan to gradually sneak up on the crash by moving things into my library and then hopefully into Pharo via FFI. > > > > On Windows, I would use OutputDebugString() to write tracing messages to look at what is happening until I found the problem. How do you unix VM gurus tackle such debugging problems? > > > > Bill, > > To write strings to output, use fprintf() followed by fflush(). > Don't forget the fflush or you'll never figure anything out ;) > > To use a debugger, compile with CFLAGS=-g (enable debugging info, no compiler optimization), then run the VM under gdb or one of the gui front ends to gdb such as ddd. Put a breakpoint in your function, and you're good to go. > > Assuming you are using up to date sources from Subversion, run "platforms/unix/configure --help" for more build options. > > Dave > > > _______________________________________________ > 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

July 13, 2010

Re: [Pharo-project] Sequential Dictionary

by Joel Turnbull

Thank you, it's working beautifully HernÃ¡n :) 2010/7/12 HernÃ¡n Morales Durand <hernan.morales(a)gmail.com> > Hi Joel, > > You may try the attached OrderedDictionary, I've been using it for some > time. > Cheers, > > HernÃ¡n > > 2010/7/12 Joel Turnbull <joelbywan(a)gmail.com>: > > > > Spent some time but was not quite able to get OrderedDictionary working. > > However I see the idea is for the Dictionary to hold an OrderedCollection > > that is synchronized with the Dictionary's array. > > > > I think that's enough for me to go on to implement my own for the limited > > dictionary protocol I need to support. > > > > I looked in the Seaside packages for subclasses of Dictionary, or classes > > named like Dictionary, but I didn't find anything. > > > > I got a little lost looking at BTree, I should probably take the time to > > look at that someday. > > > > Thanks guys. > > > > > > > > On Sun, Jul 11, 2010 at 11:45 AM, Levente Uzonyi <leves(a)elte.hu> wrote: > >> > >> On Sun, 11 Jul 2010, Joel Turnbull wrote: > >> > >>> What is the group's recommendation for creating a sequential > Dictionary? > >>> i.e. A Dictionary who's associations are ordered. > >>> > >>> Is there any precedent for this? Or does it sound like I'm barking up > the > >>> wrong tree? > >>> > >>> In my model, I've subclassed Dictionary into QuantityDictionary to > store > >>> line items, where the key is the item and the value is the quantity of > >>> the > >>> item. It validates that the value is always a numeric, removes the > >>> association when the value goes below zero, and other stuff specific to > >>> my > >>> application. > >>> > >>> Now I'm finding it makes sense to be able to order these associations. > >>> Imagine a recipe ingredient list, where you add and edit quantities of > >>> ingredients, and you want to put the ingredients that you use earliest > in > >>> the recipe at the top of the ingredient list. > >>> > >>> Before I put any more work into it, I just wanted to make sure that a > >>> sequential dictionary makes sense, and get your ideas on how to > generally > >>> go > >>> about implementing that? > >> > >> A "sequential dictionary" can mean a lot of different things. There are > >> some implementations with different semantics available. See these for > >> example: > >> http://squeaksource.com/BTree.html > >> http://forum.world.st/OrderedDictionary-td277320.html > >> > >> If you just want to iterate over your dictionary once in the sorted > order, > >> then the best thing to do is to collect your data into an array, sort > the > >> array, then iterate over that sorted array. > >> > >> > >> Levente > >> > >>> > >>> Thanks. > >>> > >> > >> _______________________________________________ > >> 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 >

July 13, 2010

Re: [Pharo-project] [Vm-dev] Tracing on Linux

by Schwab,Wilhelm K

Dave, I must respectfully disagree: the point is to see what Pharo "thinks" is happening in certain situations, so I need to see tracing info from it and from the library. Bill -----Original Message----- From: pharo-project-bounces(a)lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of David T. Lewis Sent: Monday, July 12, 2010 3:54 PM To: Pharo-project(a)lists.gforge.inria.fr Subject: Re: [Pharo-project] [Vm-dev] Tracing on Linux Using #stdOut from the image would not be useful for debugging a primitive or an FFI callout. Either use a real debugger (gdb et al) or put the fprintf someplace where you can see the parameters exactly as passed to the function. Dave On Mon, Jul 12, 2010 at 10:35:36AM -0400, Schwab,Wilhelm K wrote: > Dave, > > Any thoughts on mixing fprint()/fflush() in the .so with #stdOut in the image? I found #helloWorld, but some tinkering suggests that it is very sensitive to using #lf vs. #cr and/or does not like #flush. Does any of that sound familiar? > > Bill > > > > -----Original Message----- > From: pharo-project-bounces(a)lists.gforge.inria.fr > [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of > David T. Lewis > Sent: Monday, July 12, 2010 5:32 AM > To: Squeak Virtual Machine Development Discussion > Cc: Pharo-project(a)lists.gforge.inria.fr > Subject: Re: [Pharo-project] [Vm-dev] Tracing on Linux > > On Sun, Jul 11, 2010 at 05:30:35PM -0400, Schwab,Wilhelm K wrote: > > > > I am trying to track down a segmentation fault in calling into the Gnu Scientific Library. These are things that I had working under Windows+Dolphin and am now trying to do with Pharo and Linux. Offsets to structure elements and sizes of structures are possible snags, but the calls that are failing should be reasonably independent of such things: I call the relevant allocation method and pass along the pointer, so even if my interpretation of the structs is bogus, I would still expect the functions to succeed. That is all the more true of new functions that I am adding for testing purposes. > > > > The GSL functionality is split into two libraries, and the .so modules appear to be hobbled on Linux due to circular dependencies between them. A wrapper .so that is linked to both libraries seems to allow me to call "all" of the functions (the few I have tried to access) and gives a home for code of my own. > > > > I went so far as to compile some GSL sample code, and it does not crash. I further linked it to my wrapper library and it still works calling the GSL functions through the wrapper (or at least I *think* that's happening). I plan to gradually sneak up on the crash by moving things into my library and then hopefully into Pharo via FFI. > > > > On Windows, I would use OutputDebugString() to write tracing messages to look at what is happening until I found the problem. How do you unix VM gurus tackle such debugging problems? > > > > Bill, > > To write strings to output, use fprintf() followed by fflush(). > Don't forget the fflush or you'll never figure anything out ;) > > To use a debugger, compile with CFLAGS=-g (enable debugging info, no compiler optimization), then run the VM under gdb or one of the gui front ends to gdb such as ddd. Put a breakpoint in your function, and you're good to go. > > Assuming you are using up to date sources from Subversion, run "platforms/unix/configure --help" for more build options. > > Dave > > > _______________________________________________ > 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

July 12, 2010

Re: [Pharo-project] Optimize Pharo for slow horse

by StÃ©phane Ducasse

On Jul 12, 2010, at 11:16 PM, Nicolas Cellier wrote: > 2010/7/12 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> > I would love to hear more about oscar. I would love to know where the libraries could be improved to have more coherent type information. > I told him when I visited you but so far we got no feedback. We will see if there are some results. > > Stef > > > Oh, you mean following the steps of Strongtalk... Yes getting advantage of strong typing without the inconvenient. You could have checkers that help us and still have a pure dynamically typed language. Some years ago a student did an experiment at bern on that. Stef

July 12, 2010

Re: [Pharo-project] Optimize Pharo for slow horse

by Nicolas Cellier

2010/7/12 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> > I would love to hear more about oscar. I would love to know where the > libraries could be improved to have more coherent type information. > I told him when I visited you but so far we got no feedback. We will see if > there are some results. > > Stef > > Oh, you mean following the steps of Strongtalk... Nicolas > > > > Gradual typing could help there, doing optimisations where possible. Eric > has a PhD student (Oscar) working on gradual typing, with Pharo as the test > bed. Next semester there should start a second one with me (Esteban) that is > going to look at the vm side of things: if type info is available, use it to > optimise ... > > > > So, we are working on it ;-) > > > > On 12 Jul 2010, at 15:53, StÃ©phane Ducasse wrote: > > > >> - high optimized (I would be curious to know if we could "seal" > some packages and in this case use a lot of inlining > > > > -- > > Johan Fabry > > jfabry(a)dcc.uchile.cl - http://dcc.uchile.cl/~jfabry<http://dcc.uchile.cl/%7Ejfabry> > > PLEIAD Lab - Computer Science Department (DCC) - University of Chile > > > > > > > > > > _______________________________________________ > > 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 >

July 12, 2010