- Pharo-dev - lists.pharo.org

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

Re: [Pharo-project] Closure fixes

by keith

> "A. Load Gofer" > ScriptLoader new installGofer. > > "B. Install packages" > | gofer | > gofer := Gofer new. > gofer url: 'http://www.squeaksource.com/PharoTaskForces'. > Transcript cr; show: 'Part 2'; cr. > gofer copy > addAll: #( > "Part 2" > 'Kernel-MikeRoberts.405'); > load. > Transcript cr; show: 'Part 3'; cr. > gofer copy > addAll: #( > "Part 3" > 'Compiler-MikeRoberts.130' > 'CompilerTests-MikeRoberts.21' > 'KernelTests-MikeRoberts.150'); > load. > Transcript cr; show: 'Part 4'; cr. > gofer copy > addAll: #( > "Part 4" > 'Compiler-MikeRoberts.131'); > load. > Transcript cr; show: 'Part 5'; cr. > gofer copy > addAll: #( > "Part 5" > 'Kernel-MikeRoberts.406'); > load. > Transcript cr; show: 'Part 6'; cr. > gofer copy > addAll: #( > "Part 6" > 'Kernel-MikeRoberts.407'); > load. > Transcript cr; show: 'Part 7'; cr. > gofer copy > addAll: #( > "Part 7" > 'System-Changes-MikeRoberts.13'); > load. > gofer copy > addAll: #( > 'System-Download-MikeRoberts.11'); > load. > gofer copy > addAll: #( > 'System-Support-MikeRoberts.89'); > load. > Transcript show: 'Part 8'; cr. > gofer copy > addAll: #( > "Part 8" > 'Tools-MikeRoberts.202'); > load. > Transcript cr; show: 'Part 9'; cr. > gofer copy > addAll: #( > "Part 9 - setup recompile" > 'System-Support-MikeRoberts.90'); > load. > > > "C. Recompile" > Utilities initializeClosures. > Utilities compileUsingClosures. > > "D. Run the tests please" > TestRunner open > The case for installer... QED Keith

Sept. 20, 2009

Re: [Pharo-project] Gofer vs Installer

by keith

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. 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.

Sept. 20, 2009

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

by Igor Stasenko

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. -- Best regards, Igor Stasenko AKA sig.

Sept. 20, 2009

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

by T.J. Richter

Lukas Renggli <renggli@...> writes: > > > Gwenael changed the RBParser and AST to preserve code formatting. > > He never understood why nobody did look at what he did. > > I looked at it. The code did not work for me at all (it broke > everything), so I couldn't test it. > > IMHO this is not something that can be just fixed by changing the > Refactoring Browser. The refactorings are implemented as "arbitrary" > transformations/re-compositions of the AST. For a machine (e.g. the > parser, the rewrite-engine, etc.), it is not clear if a space or a > comment belongs to the AST node before or after. > > Lukas > Hi Lukas. I'm sure for some of the more complicated refactoring tools, delineating whitespace between tokens is difficult or maybe even impossible, but I don't see why a renaming tool couldn't parse the source into an AST preserving whitespace tokens as they were, then simply performing search and replace on the relevant message send tokens, then outputting the the token sources.

Sept. 20, 2009

Re: [Pharo-project] Status of Alien FFI

by Schwab,Wilhelm K

Sig, If someone finds something truly better, more power to them. I predict Pharo will be tough to beat though. Bill -----Original Message----- From: pharo-project-bounces(a)lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Igor Stasenko Sent: Sunday, September 20, 2009 2:32 PM To: Pharo-project(a)lists.gforge.inria.fr Subject: Re: [Pharo-project] Status of Alien FFI 2009/9/20 Schwab,Wilhelm K <bschwab(a)anest.ufl.edu>: > Sig, > > The term "bus factor" arose from legitimate concerns to be sure, but let's not start predicting Pharo's downfall just yet. Â At the rate things are progressing, it will become a formidable system. Â With a sound foundation, innovation will be possible without sweeping change to the system itself. Â If at some point it falls into the wrong hands, one could always branch off from a stable release and be happy for a very long time. I do not agree. No matter how well , sound, formiddable the system are. There are always a chance that you miss something, and someone will find something better. The risks i outlined in previous post is not related to the quality of software, these risks are lying in social plane, rather than technical. If you need a stable, countinuously progressing system, first thing you need is a stable community with clear vision what goals are. But when community grows exponentially, and if it happens that at some point you got a weak leadership, wrong things start happening. Just because the probability of it is higher than before :) > > Who is asking for backward-compatibility? Â Is it the Squeak community, or Pharo users? > Ask the same question after 5-10 years :) > Bill > > > -----Original Message----- > From: pharo-project-bounces(a)lists.gforge.inria.fr > [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Igor > Stasenko > Sent: Sunday, September 20, 2009 1:44 PM > To: Pharo-project(a)lists.gforge.inria.fr > Subject: Re: [Pharo-project] Status of Alien FFI > > 2009/9/20 Marcus Denker <denker(a)acm.org>: >> >> On 20.09.2009, at 13:49, StÃ©phane Ducasse wrote: >> >>> They probably moved while we got stuck. >> >> It's like with money: there is an "inflation" of constant progression. >> Everthing gets better slowly but constantly. >> Over 10 years, this results in quite some progress. >> >> Especially as you get the effect of "compound interest": By making >> something a little bit better, the next step of making it again a >> little bit better gets a little bit easier. >> >> As with compound interest, the effect is non-linear and completely >> against human intuition. >> >>> This is all the story behind pharo: moving again. >> >> What one needs to ask is always: How great could a system be over >> time if one would just do the next trivial, tiny, small step? And >> that over 10 years? With Squeak, this was impossible. Every small >> improvement was directly criticised as beeing "not good enough" and >> thus not worthwile for Squeak. With that attitude you go nowhere. As >> was proven in 10 years with Squeak. >> >> Of course, you should not *just* do tiny improvements. But it's like >> investing: there >> might be the chance to buy some pre-ipo stock cheap in the future. >> Does that mean >> that I put the money under the bed for no interest, or do I invest it >> for some tiny percentage e.g in a money-market account the meantime? >> With Squeak, the community decided that doing nothing was the right >> thing. >> >> Â Â Â Â Marcus >> > > (wearing a devil's advocate hat) > > I fear that Pharo, at some day could repeat the fate of Squeak. > At version 2.0, 3.0 or whatever, you will lose interest (for whatever > reason) in supporting it and > step down from leading the project, as well as other current developers. > The people who will lead it next will have a bit less authority to change anything, and there already will be a certain 'backwards compatibility' pressure from community. > Also, much more people will not feel so confident in new leaders comparing to you, simply because they could not know much about them, or because they are not founders etc etc. > In this situation, if someone will raise a hand, and say - lets throw out X, and replace it with Y, because its better, will have a high chances to be burned out. > > (wearing off a devil's advocate hat) > > I hope that there are a good strategy behind activities in Pharo, to not let the progress slowdown. > And if not, then it is right time to think about it. > >> >> -- >> Marcus Denker - http://marcusdenker.de 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 >> > > > > -- > Best regards, > Igor Stasenko AKA sig. > > _______________________________________________ > 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. _______________________________________________ Pharo-project mailing list Pharo-project(a)lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Sept. 20, 2009