November 2011 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] Athens work in progress: couple screenshots

by Fernando Olivero

I've implied using meta-programming,in order to have a uniform protocol in the abstract Canvas. AthensCanvas>>transformDescribedBy: aName self perform: ( aName , 'Transform' ) asSymbol . But i see that your approach is simpler, there's no need for a uniform protocol because when you are using a particular AthensCanvas you are fully aware of that! Regarding the build, after a lonnnngg series of errors, i also managed to build universal binaries of Cairo, using MacPorts (brew just doesn't ease the task of creating 32 bit libraries). sudo port cairo +universal, worked for me, taking at least 30 min to build. ATTENTION: Before entering the port cairo install command, I've had to manually install appleGcc4.2, found @ [1] (file name gcc-42-5666.3-darwin11.pkg. Given that i have Lion, XCode4.2, and if you just allow macports to build appleGcc4.2, it will run a process that consumes resources and finally stalls your computer! I've attached a screen shot that may help somebody else, for setting up the examples. Using NativeBoost Cog VM for Mac, downloadable from NativeBoost site or Jenkins. Great work Javier, and Igor! I'm looking forward to implement a Text editor using Cairo+Pango + "my new morphic". Fernando [1] http://r.research.att.com/tools/ On Tue, Nov 29, 2011 at 5:02 PM, Igor Stasenko <siguctua(a)gmail.com> wrote: > On 29 November 2011 16:12, Fernando Olivero <fernando.olivero(a)usi.ch> wrote: >> I get the point now, something like the brushes in seaside. >> Thanks for the explanation. >> >> Regarding the protocol, did you consider reusing the same idea, but >> one step before, as in the following: >> >> pathTransform := canvas transformDescribedBy: 'path'. >> pathTransform scaleBy: 0.5. >> >> imageTransform := canvas transformDescribedBy: 'image'. >> imageTransform scaleBy: 0.5. >> >> Maybe add the following for documentation: >> >> AthensCairo>>availableTransforms >> Â Â Â Â Â Â Â ^ #('path'. 'image'. ) >> >> AthensOpenGL>>availableTransforms >> Â Â Â Â Â Â Â ^ #('modelView'. 'projection'. ) >> >> This would unify the canvas protocol, for all the available rendering engines. >> > > This sounds more complicated. We can map different matrices in > different engines to Athens. > So, it is not necessary for client code to know which of them are > there, because then code will be > filled with tons of Â #ifTrue: branches ... . > > > > -- > Best regards, > Igor Stasenko.

Nov. 30, 2011

[Pharo-project] [ VM ]Smalltalk getSystemAttribute:

by StÃ©phane Ducasse

we will have to check if this impacts some of our parameter handling. Stef Begin forwarded message: > VM.r2518/. > > CogVM binaries as per VMMaker.oscog-eem.139/r2518. > > Add access to VM arguments to Mac. Make Windows, Mac and Unix consistent: > Smalltalk getSystemAttribute: > -1 => executable name > -2 .. -n => VM arguments *including* image (if explicitly supplied). > Replace win32 command line parsing with unixesque code using CommandLineToArgvW. > > linux launch script: > Cope with old linuxes use of /lib/tls hack for an optional thread-local-storage > version of libc/libpthread. The launch scripts add /lib/tls:/usr/lib/tls: to > LD_LIBRARY_PATH instead of /lib:/usr/lib: if the VM is linked to /lib/tls/libc. > -- > best, > Eliot >

Nov. 30, 2011

Re: [Pharo-project] object format of true, false, nil and others...

by Igor Stasenko

On 30 November 2011 00:17, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: > > > On Wed, Nov 23, 2011 at 2:25 PM, Stefan Marr <pharo(a)stefan-marr.de> wrote: >> >> Hi: >> >> On 23 Nov 2011, at 22:59, StÃ©phane Ducasse wrote: >> > imagine that I want to bootstrap our nice kernel. >> > I will need to somehow create a new nil, true, false, instances of new >> > classes Undefined, True, False. >> > Such instances will then be put on the SpecialObjectArray somehow. >> >> Something kind of related: >> >> When debugging the VM, I am happy that I always encounter the same object >> as the first object in the heap. It is some strange string (think it encodes >> an error message or so). >> >> However, my thought was, also for other purposes, would it be possible to >> have these special objects sorted to the beginning? Especially, the nilObj >> would be very handy to have as the first object. > > > Note that Cog assumes that false and true are next to each other. Â You'll > find in all Pharo/Squeak images that the first three objects are nil, false, > true in that order. Â Assuming they're contiguous allows the JIT to generate > more compact conditional branch code since true = false + 8, and so it only > has to load one 32-bit constant and can derive the other by adding a small > constant. > >> >> That would need special VM support to arrange it that way, but knowing the >> nilObj from the very beginning would allow my to initialize some of my hacks >> more consistently, avoiding C-level NULLs and runtime checks. > > > It's safe to assume nil comes first. Â One can imagine experimental contexts > where one would want to become nil but the current VMs will very likely > crash without some work. Â But why waste cycles on every run when it is so > unlilkely anyone will try this? > even more, since nil, true, false are stateless singletons there is no much sense to use heap space for them. they could be identified by a simple immediate value (like non-existent address). Even if we imagine some weird experiment with objects , i doubt we will need to touch these objects at all. Because they are representing a concepts which cannot be void or replaced by something else. -- Best regards, Igor Stasenko.

Nov. 30, 2011

Re: [Pharo-project] VM page in pharo book is outdated

by Schwab,Wilhelm K

FFI isn't so much difficult as it is a little tedious and, more so, incomplete. Stef has said that a working FFI (callbacks and threads) for all platforms is a priority, and is using words like January - that would be NICE. I would also like to see a full set of signed/unsigned single, double and perhaps quad word arrays, as well as float and double arrays. The latter is truly missing; I have been very lucky hacking around it. One thing that is really a shame is that for any of my extended types, I have to tell FFI that they are void* :( At least that's the only way I currently know to get them to work. C++ libraries might be a problem. In one case, I was able to simply tell FFI about the mangled names, and all was well. If the library goes heavily into C++ features across its boundary, you might be better off writing a C-friendly wrapper around it. Remember that once you get inside the opening brace of even an extern "C" function, you can use C++ features to implement it. In particular, I have C callable functions that use string streams to generate output and templated array classes to access elements. Bill ________________________________________ From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] on behalf of Serge Stinckwich [serge.stinckwich(a)gmail.com] +1 I would love to use Pharo to do more robotics/embedded stuff. For example, i would like to be able to connect C/C++ computer vision libraries like OpenCV with FFI/Alien. But this is still difficult to do that in Pharo. I don't have the energy and man-power to invest time in this direction. If i ask some students do to this work, i know that they will have a lot of difficulties and at end the experience will be not very funny. Regards, -- Serge Stinckwich UMI UMMISCO 209 (IRD/UPMC), Hanoi, Vietnam Matsuno Laboratory, Kyoto University, Japan (until 12/2011) http://www.mechatronics.me.kyoto-u.ac.jp/ Every DSL ends up being Smalltalk http://doesnotunderstand.org/

Nov. 30, 2011

Re: [Pharo-project] VM page in pharo book is outdated

by Guillermo Polito

On Tue, Nov 29, 2011 at 10:12 PM, Serge Stinckwich < serge.stinckwich(a)gmail.com> wrote: > On Tue, Nov 29, 2011 at 10:12 PM, Esteban Lorenzano <estebanlm(a)gmail.com> > wrote: > > Hi, > > > > Checking the pharo colaboractive book, I found that the VM building is > old and it is not compatible anymore with our current process. Maybe > "someone" (cough, cough, Mariano, cough, cough) could update it with better > information? > > > > Cheers, > > Esteban > > > > pd: also... I'm a little worried about nobody noticing this before. That > means people does not use pharo book? I think is a great way to share > information, but maybe there is not much people aware of it... I know, > there is a link in "external links" in main page and is top in > "documentation"... I don't know if we can do it more visible or clear? > > ppd: I'd rearrange "pharo tools" section by adding subsections like: > "Persistence", "Web", etc., today looks a little bit confusing, IMHO. > > pppd: yeah... today is my "stupid questions" day... :P > > There is the Pharo by Example book (Vol 1 and vol 2) and the Pharo > Collaboractive book. I'm wondering if this is a kind of dispersion to > have two books at the same time. > What is the idea of Pharo Collaborative book ? More focused on Pharo > applications ? a Pharo user manual ? > What about calling it PharoWiki? > > Maybe some chapters maybe be shared between the two books. > > Regards, > -- > Serge Stinckwich > UMI UMMISCO 209 (IRD/UPMC), Hanoi, Vietnam > Matsuno Laboratory, Kyoto University, Japan (until 12/2011) > http://www.mechatronics.me.kyoto-u.ac.jp/ > Every DSL ends up being Smalltalk > http://doesnotunderstand.org/ > >

Nov. 30, 2011

Re: [Pharo-project] VM page in pharo book is outdated

by Serge Stinckwich

On Tue, Nov 29, 2011 at 10:12 PM, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > Hi, > > Checking the pharo colaboractive book, I found that the VM building is old and it is not compatible anymore with our current process. Maybe "someone" (cough, cough, Mariano, cough, cough) could update it with better information? > > Cheers, > Esteban > > pd: also... I'm a little worried about nobody noticing this before. That means people does not use pharo book? I think is a great way to share information, but maybe there is not much people aware of it... I know, there is a link in "external links" in main page and is top in "documentation"... I don't know if we can do it more visible or clear? > ppd: I'd rearrange "pharo tools" section by adding subsections like: "Persistence", "Web", etc., today looks a little bit confusing, IMHO. > pppd: yeah... today is my "stupid questions" day... :P There is the Pharo by Example book (Vol 1 and vol 2) and the Pharo Collaboractive book. I'm wondering if this is a kind of dispersion to have two books at the same time. What is the idea of Pharo Collaborative book ? More focused on Pharo applications ? a Pharo user manual ? Maybe some chapters maybe be shared between the two books. Regards, -- Serge Stinckwich UMI UMMISCO 209 (IRD/UPMC), Hanoi, Vietnam Matsuno Laboratory, Kyoto University, Japan (until 12/2011) http://www.mechatronics.me.kyoto-u.ac.jp/ Every DSL ends up being Smalltalk http://doesnotunderstand.org/

Nov. 30, 2011

Re: [Pharo-project] VM page in pharo book is outdated

by Serge Stinckwich

On Wed, Nov 30, 2011 at 6:51 AM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > >> Hi Esteban. I DID notice that the book was "outdated". The thing is that we have to decide, as the Pharo community, if it is outdated or just another alternative. >> Eliot's way of building the VM is different than "our". We use ConfigurationOfCog + CMakeVMMaker + Git. Eliot uses another way. >> So what is documented in the pharo book is kind of Eliot way. >> We have to decide as a community what do we expect when building cog. Is ConfigurationOfCog + CMakeVMMaker + Git the OFFICIAL Pharo way of building the VM? Â If we do agree on this, then yes, we should update the book. Something different is if ConfigurationOfCog + CMakeVMMaker + Git is just ANOTHER way of bulding the VM, in which case I don't see as incorrect what is in the pharo book. > > > Guess my answer :) > Why would we throw away the three months igor spent making sure that idiot like me can compile the VM without problems. > And more important Git (which I hate for my article) is socially the way to go for the VM = message to cool C hackers > yes you are welcome to clean and improve our VM (it deserves it and once of these days we will have to do somethingâ¦ because > we are losing against simpler, nicer VM like lua (C-embedding, â¦.). > JB is fighting to get the stack vm compiling on a funky micro pro and the VM dusty code is getting in our way. +1 I would love to use Pharo to do more robotics/embedded stuff. For example, i would like to be able to connect C/C++ computer vision libraries like OpenCV with FFI/Alien. But this is still difficult to do that in Pharo. I don't have the energy and man-power to invest time in this direction. If i ask some students do to this work, i know that they will have a lot of difficulties and at end the experience will be not very funny. Regards, -- Serge Stinckwich UMI UMMISCO 209 (IRD/UPMC), Hanoi, Vietnam Matsuno Laboratory, Kyoto University, Japan (until 12/2011) http://www.mechatronics.me.kyoto-u.ac.jp/ Every DSL ends up being Smalltalk http://doesnotunderstand.org/

Nov. 30, 2011

Re: [Pharo-project] Pharo VMs should be more Pharo-like

by Serge Stinckwich

On Tue, Nov 29, 2011 at 9:46 PM, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > Hi, > > Currently, we are linking official VMs Â for pharo taking directly from Jenkins a version and packaging for download (or for Pharo One-Click). > I think this is a temporal solution, we need something better: > > 1) Pharo VMs should have Pharo Icons. > 2) Pharo VMs should be named "pharo" or "pharovm" (better the fist), not "CogVM", which is an internal name. > 3) We should include a PLUGINS.txt file with information about present plugins (internal and external) > 4) We should include a LICENCE.txt file with all licence information. > > ... I think that's all :) > > > > I know... this is very dumb and clearly not mandatory, but it says a lot about the maturity of our Pharo :) > > All agree? Should I create a ticket? Yes, nobody could disagree with that ;-) > Cheers, > Esteban > > pd: I'm the only one who does not likes One-Click versions? I would prefer a different package for each platform (Is ugly to have a directory named Pharo.app in linux or windows. Also, no need to have all those duplicated-but-for-different-platform files) Most of the time, i'm using One-click images. This is really convenient to move images between machines and give them to friends. If the process of creating releases is automated, both can be provided. Regards, -- Serge Stinckwich UMI UMMISCO 209 (IRD/UPMC), Hanoi, Vietnam Matsuno Laboratory, Kyoto University, Japan (until 12/2011) http://www.mechatronics.me.kyoto-u.ac.jp/ Every DSL ends up being Smalltalk http://doesnotunderstand.org/

Nov. 30, 2011

Re: [Pharo-project] object format of true, false, nil and others...

by Eliot Miranda

On Wed, Nov 23, 2011 at 2:25 PM, Stefan Marr <pharo(a)stefan-marr.de> wrote: > Hi: > > On 23 Nov 2011, at 22:59, StÃ©phane Ducasse wrote: > > imagine that I want to bootstrap our nice kernel. > > I will need to somehow create a new nil, true, false, instances of new > classes Undefined, True, False. > > Such instances will then be put on the SpecialObjectArray somehow. > > Something kind of related: > > When debugging the VM, I am happy that I always encounter the same object > as the first object in the heap. It is some strange string (think it > encodes an error message or so). > > However, my thought was, also for other purposes, would it be possible to > have these special objects sorted to the beginning? Especially, the nilObj > would be very handy to have as the first object. > Note that Cog assumes that false and true are next to each other. You'll find in all Pharo/Squeak images that the first three objects are nil, false, true in that order. Assuming they're contiguous allows the JIT to generate more compact conditional branch code since true = false + 8, and so it only has to load one 32-bit constant and can derive the other by adding a small constant. > That would need special VM support to arrange it that way, but knowing the > nilObj from the very beginning would allow my to initialize some of my > hacks more consistently, avoiding C-level NULLs and runtime checks. > It's safe to assume nil comes first. One can imagine experimental contexts where one would want to become nil but the current VMs will very likely crash without some work. But why waste cycles on every run when it is so unlilkely anyone will try this? > Just an idea, vaguely related to the question. > > Would be interesting to hear whether there are any historical insights > with regard to ordering objects in the image. > Guess it is not done because nobody needed it. (and then there isn't > really a primitive for it, and a moving GC might also be contra-productive, > etc.) > > Best regards > Stefan > > > > > > > Stef > > -- > Stefan Marr > Software Languages Lab > Vrije Universiteit Brussel > Pleinlaan 2 / B-1050 Brussels / Belgium > http://soft.vub.ac.be/~smarr > Phone: +32 2 629 2974 > Fax: +32 2 629 3525 > > > -- best, Eliot

Nov. 29, 2011

[Pharo-project] [update 1.4] #14239

by StÃ©phane Ducasse

14239 ----- - Issue 5038: Optimization in list wrapping. Thanks Benjamin van ryseghem. http://code.google.com/p/pharo/issues/detail?id=5038 - Issue 5034: Harvest class comments from Squeak. Thanks Sean De Nigris. http://code.google.com/p/pharo/issues/detail?id=5034 - Issue 5033: ReferenceStream Comment: Remove underscore assignment. Thanks Sean De Nigris. http://code.google.com/p/pharo/issues/detail?id=5033 Issue 5039: FlatMessageListBrowser improvement. Thanks Benjamin van ryseghem. http://code.google.com/p/pharo/issues/detail?id=5039 Thanks Stef

Nov. 29, 2011