March 2010 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] killing a runaway process

by Lukas Renggli

> it would be really nice if i could 'control-c' the workspace and clear it out.. World | Tools | Process Browser gives you to the possibility to kill background processes. If a process blocks the complete image Ctrl+. might break it. Lukas -- Lukas Renggli http://www.lukas-renggli.ch

March 21, 2010

Re: [Pharo-project] [ANN] Gofer Project Loader 1.0 (BETA)

by Miguel Enrique CobÃ¡ Martinez

El sÃ¡b, 20-03-2010 a las 14:12 -0700, Dale Henrichs escribiÃ³: > Miguel, > > I should emphasize that conditional load/compile in Metacello is a pragmatic feature. I don't disagree that the combinatorials can quickly spiral out of control, but for the short term there is no alternative. I won't argue that conditionals _should_ be included in the package management layer, either. > > As with all other problems there are several ways to "skin the cat". I _could_ have extended Monticello to have platform-specific code components. I _could_ have added conditional compilation to the Smalltalk compiler. In many ways those solutions are uglier than putting conditional loading into Metacello:) > > In the end I added the minimum set of features to Metacello that solved the problems that I was facing on a daily basis and conditional load/compile was high on my list. > > With that said, I encourage and support any effort aimed at avoided the use of conditionals:) Dale, I agree with your arguments and I am not criticizing or commenting about the features of Metacello, I am a happy user of Metacello as you know, and it is very easy to use it. I know that the conditionals are a fundamentally pragmatic solution (an this is good, as that is the way that most real world problems are solved, by being pragmatic and solving the problem, not caring if it is pure design or not. :) But I think that with enough time (or maybe never, miracles happen, they say), Pharo and Squeak will be different enough that will be difficult that a universes scheme can work for several forks or Smalltalk versions. I think that they will need each one its own package set. For example, squeak5.0 universe will have package A, B and D pharo3.0 universe will have package B, C, H and K with package B being a ConfigurationOfB that has been copied to both repositories and that maybe have parted ways and both of them have different versions methods, for example: squeak5.0 has ConfigurationOfB version1 ConfigurationOfB version2 ConfigurationOfB version3 and pharo3.0 has ConfigurationOfB version1 ConfigurationOfB version2 ConfigurationOfB version3 ConfigurationOfB version4 ConfigurationOfB version5 And maybe even version3 is different in squeak5.0 and pharo3.0 universes. But we are theorizing, so far Metacello is working very good, we'll attack the problem when is presented. So, keep the good job you are doing Dale. Cheers > > Dale > ----- "Dale Henrichs" <dale.henrichs(a)gemstone.com> wrote: > > | Miguel, > | > | Keep in mind that the conditional load code in Metacello is the moral > | equivalent of #ifdef in C. The debian package universe has the > | advantage of pushing the conditional compilaton of _source code_ down > | a level. > | > | With Metacello, I purposely use the version attribute for conditional > | loading of code (as close to a conditional compile as you can get). In > | Metacello we do the load and the compile... > | > | Where common code can be written it should be, but as versions and > | platforms diverge in their API, something has to give ... If you can > | afford to seal off the source code for an older version then that's > | fine, but in a project that is under active development and is > | _expected_ to run on multiple versions of multiple platforms one must > | resort to "conditional loading" - conditional loading is what makes > | Grease work, BTW. > | > | When you look at the universe of #ifdef in C, you see that some of the > | ifdefs are adhoc and some of the ifdefs are based upon platform > | constants ... and that is what the metacello attributes give you ... > | Right now, you can create project-specific attributes and there are a > | handful of pre-defined attributes ... As I said, I am purposefully > | avoiding adding new pre-defined attributes willy nilly, but anticipate > | that some will be needed (GemStone3.0 and GemStone2.4 and even > | GemStone2.3 need to have difference code compiled/loaded for projects > | that are in active developement and expect to be run on all three > | versions of GemStone the low-level apis are different and different > | code has to be written for each different version). > | > | Having the conditional compile/load component in Metacello isn't > | necessarily an elegant feature, but given that no other part of the > | Smalltalk system currently provides a conditional compile/load, I > | added it to Metacello. Since I am maintaining common software on three > | different versions of gemstone, I consider it a requirement. > | > | If and when an elegant conditional compile/load solution becomes > | available, then this particular feature of Metacello can be allowed to > | die in peace. > | > | I will agree that the MYSQL maintainers don't worry whether their > | executables load on Ubuntu or Fedora, but I can almost guarantee you > | that they have conditional code that makes sure that there their code > | will compile/build on the different OSes. > | > | The ifdef world is as ugly as it comes, but it does exists for a > | pretty good reason. > | > | > | Dale > | ----- "Miguel Enrique CobÃ¡ Martinez" <miguel.coba(a)gmail.com> wrote: > | > | | El sÃ¡b, 20-03-2010 a las 21:54 +0300, George Herolyants escribiÃ³: > | | > Thanks for the explanation, Dale! > | | > > | | > May be it's obvious and I'm asking stupid questions but then I > | | don't > | | > understand how can I specify in my configuration the differences > | | > between the versions of the target platform? > | | > > | | > 2010/3/20 Dale Henrichs <dale.henrichs(a)gemstone.com>: > | | > > George, > | | > > > | | > > The mcz files containing the Metacello configurations _are_ > | | copied, but the configuration itself is not modified in the scheme. > | | > > > | | > > The idea of using different repositories is to indicate which of > | | the many different projects are _expected_ or _known_ to work in > | | Pharo1.1 or Pharo1.0. > | | > > > | | > > For GemStone, I have createed a GemSource MetacelloRepository > | and > | | I have copied the metacello configurations that I know have been > | | ported to GemStone. I've done this so that folks can know what is > | | supported. I make sure that all of the tests run green and that all > | of > | | the configs in the GemSource MetacelloRepository can be loaded. > | | > > > | | > > It does not stop someone from loading a configuration into > | | GemStone that isn't in the GemSource MetacelloRepository, but if you > | | do and run into trouble, my answer will probably be that it hasn't > | | been ported yet. > | | > > > | | > > The same thing can apply to Squeak, but someone would have to > | step > | | up to testing/approving metacello configurations that run with the > | | various versions. > | | > > > | | > > Without this extra step of approval/testing, it's difficult for > | | someone that doesn't have their finger on the pulse of the latest > | and > | | greatest happenings to know what to expect ... > | | > > > | | > > Dale > | | > | | The problem is, you are thinking in upstream development, and the > | | idea > | | of universes is that each package has maintainer for each platform > | | involved. This maintainer can be the same person that the upstream > | | developer, but it can also be someone else that make sure that a > | | given > | | package load correctly in *a give* fork. > | | > | | Making an analogy, what you are saying is that the maintainers of > | | MySQL > | | deb package in Debian should be worried about the package not > | loading > | | in > | | Ubuntu or Fedora. That is not the case. The upstream code can run in > | | all > | | of three distros, but the packages specific to each one (.deb in > | | debian > | | and ubuntu and .rpm in fedora) *must* be build and tested for their > | | own > | | maintainers. The upstream developers can rightfully don't give a > | dime > | | about where is package is being used and maybe they only release > | | a .tar.gz and know nothing (but also they don't stop efforts) about > | | external package for specific distros. > | | > | | So, returning to your question, maybe sometime in the future Squeak > | | (if > | | interested) will have to build its own repositories with its own > | | universes and put there the configurations that are proved to work > | in > | | Squeak. > | | > | | Right now as Pharo and Squeak are very similar the configurations > | | (and > | | the #common you mention) works, but this isn't going to scale for > | | different Smalltalks in the long term. > | | > | | Cheers > | | > > | | > _______________________________________________ > | | > Pharo-project mailing list > | | > Pharo-project(a)lists.gforge.inria.fr > | | > > | http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > | | > | | -- > | | 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 -- Miguel CobÃ¡ http://miguel.leugim.com.mx

March 21, 2010

[Pharo-project] killing a runaway process

by sergio_101

in order to figure out another process.. i loaded up a project to pull in twitter statuses. it looks as if it's broken, as it just keeps feeding stuff to the transcript, with no end in sight.. the first time i tried this, i realized that i hadn't saved my image for a half hour, so i lost a little bit of changes... once i realized what was happening, i realized that my image was seized up, with info dumping to the transcript.. it would be really nice if i could 'control-c' the workspace and clear it out.. any ideas? thanks! -- ---- peace, sergio photographer, journalist, visionary http://www.coffee-black.com http://www.painlessfrugality.com http://www.twitter.com/sergio_101 http://www.facebook.com/sergio101

March 21, 2010

Re: [Pharo-project] nebraska?

by Lawson English

Marcus Denker wrote: > On Mar 21, 2010, at 12:29 AM, Lawson English wrote: > >>>> Hi Marcus, actually I'm pretty sure most everyone on the Squeak side >>>> agrees with you here. The real difference is that Squeak wants to >>>> take the approach that we *do* that last step; >>>> >>> Since when? for the last 12 years, this *never* happend. >>> >>> Marcus >>> >>> >>> >>> >> So why does everyone ignore TeaTime? I admit I don't understand the internals, but it obviously *looks* like it could be the basis of Nebraska (or any other P2P solution). >> >> > Can you point me to a real good publication about it? I mean, a *real* one? > > Marcus > > Nope. In fact, I was surprised to learn that Cobalt doesn't even use TeaTime and that the last version of Croquet that used it was around 0.3. Apparently network latency for reliable message sending of an entire 3D world was greater than expected, so it was tweaked almost out of existence, at least in its original form. I am often wrong about these things of course, so corrections are welcome. OTOH, even if its NOT suitable for message sending in Croquet/Cobalt, it seems intuitively obvious that it MIGHT still be viable for use in less demanding 2D P2P scenarios. At least, I'm hoping it will be, because honestly, SVN sucks and doesn't apply at all for some of the stuff I'm hoping to use squeak for: P2P backend for plugins in virtual world viewers to share collaborative projects, obects, physics and whatever else people can come up with. One could certainly make the case that smalltalk won''t be fast enough for the high end requirements of such use-cases, but as it stands now the infrastructure really isn't in place for testing even the lowest end (person to person collaboration without requiring a web host for clunky flash based-games and drawing apps). Imagine collaborative etoys or scrabble or whatever tunning on a prim in second life, well integrated into the SL 3D environment where the etoy is controlling a 3D environment that is used by about 1 million people per month. As it stands, I can use squeak to POST messages to individual objects in Second Life and control all of their programmable behavior via a seaside-rendered GUI in a HUD object. My intent is to bypass http and directly use the Second Life media plugin to render a Morphic widow or squeak desktop onto that HUD without the overhead of SVN or http or html and and thereby create the beginnings of a squeak plugin to SL. As an aside, while people debated the utility of making it easier to embed squeak in games and such, the SL scripting team that has been working over the past 4 years to replace the Linden Scripting Langage with the mono CLR and allow C#/etc programming of SL objects, considered using Squeak as the basis for scripting the open source Second Life viewer, and rejected it because they didn't think it a viable way to go for various reasons, all of which have been raised at one point or another in the debate about embedding squeak in general. They're now planing on using mono as the basis of viewer scripting... Oh well, opportunities lost.. Lawson

March 21, 2010

[Pharo-project] [paper] Language Boxes. Bending the Host Language with Modular Language Changes

by Marcus Denker

Lukas Renggli, Marcus Denker, and Oscar Nierstrasz: Language Boxes. Bending the Host Language with Modular Language Changes In: Software Language Engineering: Second International Conference, SLE 2009, Denver, Colorado, October 5-6, 2009, LNCS 5969 p. 274â293, Springer, 2009. Abstract ====== As domain-specific modeling begins to attract widespread acceptance, pressure is increasing for the development of new domain-specific languages. Unfortunately these DSLs typically conflict with the grammar of the host language, making it difficult to compose hybrid code except at the level of strings; few mechanisms (if any) exist to control the scope of usage of multiple DSLs; and, most seriously, existing host language tools are typically unaware of the DSL extensions, thus hampering the development process. Language boxes address these issues by offering a simple, modular mechanism to encapsulate (i) compositional changes to the host language, (ii) transformations to address various concerns such as compilation and highlighting, and (iii) scoping rules to control visibility of language extensions. We describe the design and implementation of language boxes, and show with the help of several examples how modular extensions can be introduced to a host language and environment. http://scg.unibe.ch/archive/papers/Reng09cLanguageBoxes.pdf -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD.

March 20, 2010

Re: [Pharo-project] Rename DummySuperclassOfColorPickerMorph

by Gary Chambers

Try UIManager default chooseColor... That would be a potentially portable facade... Regards, Gary. On Sat, 2010-03-20 at 17:52 +0100, Mariano Martinez Peck wrote: > > > On Thu, Mar 18, 2010 at 4:19 PM, StÃ©phane Ducasse > <stephane.ducasse(a)inria.fr> wrote: > We should remove this class. It is plain bad. > For that we should replace colorPickerMorph with ColorChooser. > > > I am not sure which is the direction here. ColorPickerMorph is from > Morphic-Widgets. > ColorChoose is from Polymorph. If we change ALL places of PharoCore to > use ColorChooser instead of ColorPickerMorph we will be completely > couple to Polymorph. I mean, I would really like to be able to load > and unload Polymoprh from core without problem. So..I am not sure > which is the intention here. > > Polymorph will be in core always ? or as something optional ? > > Cheers > > Mariano > > Stef > > On Mar 18, 2010, at 4:11 PM, Mariano Martinez Peck wrote: > > > But I don't have a better name for that. Any ideas? It has > a subclass ColorPickerMorph > > > > Cheers > > > > mariano > > > > _______________________________________________ > > 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

March 20, 2010

Re: [Pharo-project] nebraska?

by Michael Rueger

On 3/20/10 4:35 PM, Marcus Denker wrote: >> So why does everyone ignore TeaTime? I admit I don't understand the >> internals, but it obviously *looks* like it could be the basis of >> Nebraska (or any other P2P solution). >> > Can you point me to a real good publication about it? I mean, a > *real* one? AFAIK TeaTime never happened but they (Croquet/Cobalt) switched to some multiplayer game like sync scheme (at least the poor me understood when I saw the implementation ;-) ). Michael

March 20, 2010

Re: [Pharo-project] nebraska?

by John M McIntosh

Burned out Sophie team members can talk to you about Tweak and TeaTime.... Don' t go there... Not that "a bit of effort" couldn't "fix it" >> So why does everyone ignore TeaTime? I admit I don't understand the internals, but it obviously *looks* like it could be the basis of Nebraska (or any other P2P solution). >> > Can you point me to a real good publication about it? I mean, a *real* one? > > Marcus -- =========================================================================== John M. McIntosh <johnmci(a)smalltalkconsulting.com> Twitter: squeaker68882 Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com ===========================================================================

March 20, 2010

Re: [Pharo-project] nebraska?

by Marcus Denker

On Mar 21, 2010, at 12:29 AM, Lawson English wrote: >>>> >>> Hi Marcus, actually I'm pretty sure most everyone on the Squeak side >>> agrees with you here. The real difference is that Squeak wants to >>> take the approach that we *do* that last step; >> >> Since when? for the last 12 years, this *never* happend. >> >> Marcus >> >> >> > > So why does everyone ignore TeaTime? I admit I don't understand the internals, but it obviously *looks* like it could be the basis of Nebraska (or any other P2P solution). > Can you point me to a real good publication about it? I mean, a *real* one? Marcus -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD.

March 20, 2010

Re: [Pharo-project] nebraska?

by Marcus Denker

On Mar 20, 2010, at 4:43 PM, Lawson English wrote: >> > > Darn. I was hoping I was getting my plug and play P2P networking on Second Life-ST-based collaboration stuff for free. > nothing is free ;-) > > The "Cobalt on a Prim" plugin should work pretty well, but its only going to be an oddity. Far more interesting will be to allow Nebraska-like/Cobalt-like sharing of applications without the extra overhead of VNC. My original plan was to somehow extract the TeaTime/Cobalt Island functionality and make it the networking layer between two instances of the Squeak-SL Plugin: > > > Second Life <=> Squeak <=> Cobalt island (sans avatars and such) <=> Cobalt island <=> Squeak <=> Second Life > > Replacing "Cobalt" with "Nebraska" looked like a much simpler way to go (on paper) but obviously, it won't work with Pharo. Eventually, Cobalt will be remerged with Trunk so that it can work with the latest Squeak or Pharo. I guess I can fudge something for P2P that isn't quite so elegant in the meantime. > Hmm... I am now expert on either of Nebraska or Croquet... but I used Nebraska over the internet (vs. local network) once: When Alan gave his keynote at CERN using my computer. We had to use a 1-bit black-and-white hacked version of nebraska and nevertheless Alan had a lag of some seconds (!!!) between what happend on my machine and what he saw via nebraska on his. Of course, the talk went *perfect* and we could have sold Squeak/Nebraska to the audience as *the* collaboration tool. But in practice, this was barely usable. (on the local network it works quite well, though). > OTOH, maybe Nebraska can be implemented on top of TeaTime/Cobalt once its available in Pharo. This is definitlly the way to go: have a good model for cross-image replication, than use that as the basis. Having two mechanisms that work completely differently is bound to make more problems than you want to deal with. Marcus -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD.

March 20, 2010