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

[Pharo-project] Fwd: [squeak-dev] About Collections-ul.137..140

by Damien Cassou

---------- Forwarded message ---------- From: Levente Uzonyi <leves(a)elte.hu> Date: Sun, Sep 20, 2009 at 4:38 PM Subject: [squeak-dev] About Collections-ul.137..140 To: squeak-dev(a)lists.squeakfoundation.org Hi! Just uploaded four packages to inbox: Collections-ul.137, Collections-ul.138, Collections-ul.139 and Collections-ul.140. These packages reimplement #rehash and #grow in Set and its subclasses (except MethodDictionary). The ideas come are from Ralph Boland's FasterSets project, but the implementation is different. According to my measurements they are even faster. The four packages should be loaded in the given order one-by-one otherwise mc might remove old methods before adding new ones, etc (couldn't come up with a better mc based load mechanism). While I was rewriting these methods, I found that KeyedSet and KeyedIdentitySet are not used (no references, no senders) in the trunk. Also checked that in a 3.8.1 full image they have no references (just senders in DecompilerTests >> #decompilerDiscrepancies). I think they might be removed from the base image and moved to a separate package. Cheers, Levente -- Damien Cassou http://damiencassou.seasidehosting.st "Lambdas are relegated to relative obscurity until Java makes them popular by not having them." James Iry

Sept. 21, 2009

[Pharo-project] Bug in OBBrowser: "Metaclass class>>does not understand: #isScarySelector:"

by Laval Jannik

Hi all, In OB Package Browser and OB System Browser, it is impossible to make a class side method. An exception appears "Metaclass class>>does not understand: #isScarySelector:" Any idea to resolve it ? Cheers --- Jannik Laval ---

Sept. 21, 2009

Re: [Pharo-project] Is there a way to use rename refactor while preserving whitespace formatting in refactored methods?

by Lukas Renggli

> This sounds like it would be very useful. Renaming things is one of the most > common kinds of refactorings, and if it can be done automatically without users > having to worry about it altering surrounding code unnecessarily, that would be > wonderful. The nice thing of the Smalltalk Refactoring Engine is that it all builds uniformly on top of the rewrite engine. Unfortunately this makes it very hard to preserve the formatting. > Out of curiosity, is there some kind of global, RegExp-based search and replace > functionality in the system that can be used instead? I've built a set of code transformations on top of the refactoring engine (so that undo/redo works) that use regular expressions (and thus preserve the formatting). These tools allows you to transform category names, class names, protocol names, selector names and source code using regular expressions. The tools are implemented in OB-Regex and are directly integrated into OmniBrowser. You get the tools when you build an image from this load script for example: <http://code.google.com/p/pharo/wiki/ImageBuildScripts>. Cheers, Lukas -- Lukas Renggli http://www.lukas-renggli.ch

Sept. 21, 2009

Re: [Pharo-project] Is there a way to use rename refactor while preserving whitespace formatting in refactored methods?

by T.J. Richter

Igor Stasenko <siguctua@...> writes: > > FIY, i have implemented the smalltalk source tokenizer, > which capturing everything, including whitespace. > And, of course, i got the parser which works on top of that, which > means, that potentially i could write a code which replacing > a single token by different one , like #foo to #bar, while preserving > the white space formatting, comments & everything else. > This sounds like it would be very useful. Renaming things is one of the most common kinds of refactorings, and if it can be done automatically without users having to worry about it altering surrounding code unnecessarily, that would be wonderful. Out of curiosity, is there some kind of global, RegExp-based search and replace functionality in the system that can be used instead?

Sept. 21, 2009

Re: [Pharo-project] Gofer vs Installer

by keith

>> >> I always thought that you guys didnt actually understand installer. >> > Which is partly your own fault. How so? I may have been lax at many things, but on leaving Installer unexplained, I cant see that charge sticking. 1 - Installer was documented from the beginning, on the swiki, and in the class comment 2 - the first line of the documentation states that it is a DSL for installing things 3 - the second line of the documentation talks about executing scripts in the workspace. 4 - Installer has been available and used by many people for 3 years - Pharo are the only people routinely misusing it as far as I know. I have talked about having a strategic pan-fork approach until I am blue in the face, to the point of exhaustion. What I am left with is some mysterious unanswered questions. Like why hasn't my arm been bitten off for this stuff, and how does anyone actually get anything done with Universes? Keith

Sept. 21, 2009

Re: [Pharo-project] Status of Alien FFI

by Igor Stasenko

To add some OT and concerns about Lua & really cool stuff, see this video http://vimeo.com/5254161 it looks like right now we (smalltalkers and 3D game-devs, who are certaintly ones who are on a bleeding edge of technology) are living in different dimensions, and both of us know little about each other.. what i find really frustrating. The guy who narrating the video, came to conclusion, that its cool to be able to simply copy the code snippet & run it on different host/project without recompiling C++ stuff, also mentioned that operating on entity level (by scripting particular object(s)) makes life much easier, especially when project complexity grows and grows bigger.. I just wonder , if Lua is so good for him, what would he say, when discover the smalltalk, and especially its environment, which inherently allows to work with objects in real time without edit-recompile-run cycle. :) 2009/9/21 Schwab,Wilhelm K <bschwab(a)anest.ufl.edu>: > Good luck. Â For my time and money, fool me once, shame on you, ... > > Bill > > > > -----Original Message----- > From: pharo-project-bounces(a)lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Lawson English > Sent: Sunday, September 20, 2009 7:13 PM > To: Pharo-project(a)lists.gforge.inria.fr > Subject: Re: [Pharo-project] Status of Alien FFI > > Schwab,Wilhelm K wrote: >> Sig, >> >> If someone finds something truly better, more power to them. Â I predict Pharo will be tough to beat though. >> >> Bill >> >> > > Not to rain on anyone's parade, but C# 4.0 is just around the corner and MS is obviously grabbing features from everyone in existence... > > > Lawson > > _______________________________________________ > 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 > -- Best regards, Igor Stasenko AKA sig.

Sept. 21, 2009

Re: [Pharo-project] Status of Alien FFI

by Lawson English

Not meant as a promotion of C# 4, just an observation about MS marketing power and R&D resources... The C# 4.0 IDE gives you scripting language prototyping capabilities roughly equivalent to Python's, at least according to the MS promo videos. Lawson Schwab,Wilhelm K wrote: > Good luck. For my time and money, fool me once, shame on you, ... > > Bill > > > > -----Original Message----- > From: pharo-project-bounces(a)lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Lawson English > Sent: Sunday, September 20, 2009 7:13 PM > To: Pharo-project(a)lists.gforge.inria.fr > Subject: Re: [Pharo-project] Status of Alien FFI > > Schwab,Wilhelm K wrote: > >> Sig, >> >> If someone finds something truly better, more power to them. I predict Pharo will be tough to beat though. >> >> Bill >> >> >> > > Not to rain on anyone's parade, but C# 4.0 is just around the corner and MS is obviously grabbing features from everyone in existence... > > > Lawson > > _______________________________________________ > 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. 21, 2009

Re: [Pharo-project] Gofer vs Installer

by Igor Stasenko

2009/9/21 keith <keith_hodges(a)yahoo.co.uk>: > > On 19 Sep 2009, at 22:06, StÃ©phane Ducasse wrote: > >>>> >>>> >>>>> goals? >>>> >>>> Perform MC actions (load, update, merge, revert, commit, diff, >>>> recompile) on a set of packages. >>> >>> So, not like Installer that can load packages from everywhere, Gofer >>> will concentrate on MC? What about ScriptLoader? >> >> ScriptLoader will certainly use gofer to install packages instead of >> installer >> > > I always thought that you guys didnt actually understand installer. > Which is partly your own fault. As for the rest of post i agreeing with you. Except, maybe that Gofer may be targeted not only as cross-fork but for cross-dialect tool. But i don't have any info on that, and indeed, i think Installer , with some refactorings could also work as a cross-dialect tool, at least on platforms which already supporting MC. > Installer is intended to fulfill a strategic role, it has a role > "Installing things", and it is extensible, so that anyone else who > wants to "Install things" can contribute to it and extend it. So when > a user wants to Install things, there is a logical place to go, that > is called "Installer" for installing things. > > If you want to create an additional tool for "installing things" then > why not consider how this tool may provide facilities for installer. > Otherwise this indicates that the whole design concept and envisioned > role of Installer has been overlooked. > > There is nothing wrong with ScriptLoader per se, but to be consistent > with the vision for Installer it would be provided as an extension to > Installer, thus... > > Installer scriptloader doWhateverYouWantHere. > > Installer was created to be the first and only dependency for kernel > images of any kind, that you can use to load additional things. > > You guys come along and use ScriptLoader for roughly this purpose, > thus explicitly ignoring, and implicitly undermining this goal from > the outset. Furthermore none of your scripts in script loader appear > to take advantage of the second installer feature. > > which is... > > Installer is supposed to enable scripts to be written and executed > piecemeal, i.e. bit by bit, in a workspace, or for debugging. i.e. > Installer scripts do not , and should not use temporaries. > > i.e. this style of code is NOT suitable for this purpose. > > | repo | > > Â Â Â Â repo := Installer squeaksource project: 'This'. > > Â Â Â Â repo install: 'That'. > > A better code example which has no method temporaries is shown below > > Installer squeaksource project: 'This'; install: 'That'. > Installer monticello http: 'www.myrepo.com'; rememberAs: #mine. > Installer mine project: 'This'; install: 'That'. > > Installer is supposed to provide a uniform API as a front end for all > code loading tools > > so if this new gofer thing comes along, its API (implemented on > InstallerGofer perhaps) could be published as > > Installer gofer project: 'This'; addPackage: 'That'; addPackage: > 'TheOther'; install. > > or > > Installer gofer project: 'This'; addPackage: 'That'; addPackage: > 'TheOther'; merge. > > I think that it would be a shame if the gofer tool whatever it is, > doesn't come with an Installer api, then it would not be contributing > to the Installer story, it would be competing with it, in the same > strategic space. > > Given the fragmentation that is continuing to occur in the speak > community, I think that this is tragic, that we end up with so many re- > inventions of the wheel, yet none of them actually fulfills the role > that, if you sit down and think about it for a few minutes, we > actually need > > I.e. the original invention of Installer was expressly so that EVERY > base image published would at least have Installer loaded (or > loadable) and users could build from there, using whatever tools, and > a consistent API. > Installer helps this along in some situations since it knows how to > load the source from an MC package in the event that MC is not > actually loaded, and this helps with bootstapping Monticello etc. > > If everyone uses, or has the option of using the same tools for > building images, in every release, then this facilitates exchange of > packages among forks, and helps those of us who are not at liberty to > jump ship on a whim, and it helps those who do want to jump ship on a > whim. > > I was asking you for months to think along these lines and make such > strategic choices based upon contributing to things that the squeak > communities have in common or might want to use in common... > > The vision for Installer was to be a base for building derived images > in all release images in all forks. > The vision for MC1.5 was to be a set of tools that actually worked to > load code in all images in all forks. > The vision for LevelPlayingField is to provide bootstrapping for > difficult code to load in all images in all forks. > The vision for Sake/Packages was to be a universal set of package > definitions and dependencies that show what works where in ALL images, > in ALL Forks. > The vision for SUnit-improved was to be a universal means for defining > SUnit and SSpec tests for ALL images so that it is possible to > indicate what works where, in ALL forks, so that packages of tests can > be maintained in common for ALL forks. > > So, may I appeal to you, please contribute to and use installer, > rather than compete with it, and perhaps reconsider your approach to > the other ideas listed above. > > Keith > > p.s. I am considering, recruiting members for an independant "guild" > of package developers, whose role would be to promote interoperability > between squeak forks, so that packages can be developed once and > deployed anywhere. I think this is needed because now we have no core > image developers in either squeak or pharo, that look at > interoperability. > > > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- Best regards, Igor Stasenko AKA sig.

Sept. 21, 2009

Re: [Pharo-project] Status of Alien FFI

by Schwab,Wilhelm K

Good luck. For my time and money, fool me once, shame on you, ... Bill -----Original Message----- From: pharo-project-bounces(a)lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Lawson English Sent: Sunday, September 20, 2009 7:13 PM To: Pharo-project(a)lists.gforge.inria.fr Subject: Re: [Pharo-project] Status of Alien FFI Schwab,Wilhelm K wrote: > Sig, > > If someone finds something truly better, more power to them. I predict Pharo will be tough to beat though. > > Bill > > Not to rain on anyone's parade, but C# 4.0 is just around the corner and MS is obviously grabbing features from everyone in existence... Lawson _______________________________________________ Pharo-project mailing list Pharo-project(a)lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Sept. 21, 2009

Re: [Pharo-project] Status of Alien FFI

by Lawson English

Schwab,Wilhelm K wrote: > Sig, > > If someone finds something truly better, more power to them. I predict Pharo will be tough to beat though. > > Bill > > Not to rain on anyone's parade, but C# 4.0 is just around the corner and MS is obviously grabbing features from everyone in existence... Lawson

Sept. 21, 2009