- Pharo-dev - lists.pharo.org

Re: [Pharo-project] Origins [poll]

by Alexandre Bergel

Jan. 6, 2011

Re: [Pharo-project] Origins [poll]

by GermÃ¡n Arduino

Jan. 6, 2011

[Pharo-project] controlling the size of a morph embedded in a morphtreemorph

by Tudor Girba

Hi (Alain :)), I am trying to embed morphs into a MorphTreeMorph, but I cannot seem to be able to control the size. Please take a look at the screenshot in the attachment. On the right hand side I have a tree morph that lists all methods, and when I expand a selector, I see the source code. Now, I would like to have the followings: - the text morph fill the entire horizontal space - the text morph expand on the vertical, too - the label fill the entire horizontal space I tried to: - set the MorphTreeMorph to have lastColumnUnbounded, and - the morph layout to (fullFrame: (LayoutFrame fractions: (0 @ 0 corner: 1 @ 1))) but it did not work. Does anyone have an idea? If you want to take a look at the example, you need Glamour: Gofer new squeaksource: 'Glamour'; package: 'ConfigurationOfGlamour'; load. (Smalltalk at: #ConfigurationOfGlamour) perform: #loadDefault. and then: GLMOtherExamples new expander openOn: Collection withAllSubclasses. Cheers, Doru -- www.tudorgirba.com "What we can governs what we wish."

Jan. 6, 2011

Re: [Pharo-project] Origins [poll]

by Miguel CobÃ¡

;) but wikis are boring and the entrance price is higher compared to replying a mail. Also, is just for fun. I think that the list will bring some surprises relative to the place in the world where Pharo is reaching. Cheers El miÃ©, 05-01-2011 a las 21:37 -0200, csrabak(a)bol.com.br escribiÃ³: > Miguel, > > You rather create a wiki page (or edit the one Stef intends to put our pictures in a near future ;-) > > my 0.01999... > > -- > Cesar Rabak > > Name|Native Language|Greeting in native lang|Born country|Writing from > Cesar Rabak |Spanish/Portuguese/Italian|Hola/OlÃ¡/Ciao|Peru|SÃ£o Paulo, SP - Brazil > > > > Em 05/01/2011 19:38, Miguel CobÃ¡ < miguel.coba(a)gmail.com > escreveu: > It is a new year and I thought that it would be good to know from which > part of the world each person in this list is (or was born), so we can > get a better look at the diversity of the community. > > I start: > > Name|Native Language|Greeting in native lang|Born country|Writing from > > Miguel CobÃ¡|Spanish|Hola|Mexico|Mexico City,Mexico > > Cheers -- Miguel CobÃ¡ http://twitter.com/MiguelCobaMtz http://miguel.leugim.com.mx

Jan. 5, 2011

Re: [Pharo-project] why (MCPackage named: 'NonExistenPackage') unload. doesnt fail ?

by csrabak＠bol.com.br

Joining the canvassing campaign done by Bill: *by all means, please, NO!* -- Cesar Rabak Em 05/01/2011 19:53, Mariano Martinez Peck < marianopeck(a)gmail.com > escreveu: Do we want that? I am finding a lot of outdated code that uses code like that and it doesnt fail, but still doesnt unload the package. For example, cleanUpForRelease does a (MCPackage named: 'HelpSystem') unload. and that package doesnt exist anymore since it was split.... so...do we want that silent behaviour ? cheers mariano

Jan. 5, 2011

Re: [Pharo-project] Origins [poll]

by csrabak＠bol.com.br

Miguel, You rather create a wiki page (or edit the one Stef intends to put our pictures in a near future ;-) my 0.01999... -- Cesar Rabak Name|Native Language|Greeting in native lang|Born country|Writing from Cesar Rabak |Spanish/Portuguese/Italian|Hola/OlÃ¡/Ciao|Peru|SÃ£o Paulo, SP - Brazil Em 05/01/2011 19:38, Miguel CobÃ¡ < miguel.coba(a)gmail.com > escreveu: It is a new year and I thought that it would be good to know from which part of the world each person in this list is (or was born), so we can get a better look at the diversity of the community. I start: Name|Native Language|Greeting in native lang|Born country|Writing from Miguel CobÃ¡|Spanish|Hola|Mexico|Mexico City,Mexico Cheers -- Miguel CobÃ¡ http://twitter.com/MiguelCobaMtz http://miguel.leugim.com.mx

Jan. 5, 2011

Re: [Pharo-project] Issue 3436 in pharo: #copyFrom: is broken

by pharo＠googlecode.com

Comment #12 on issue 3436 by cesar.rabak: #copyFrom: is broken http://code.google.com/p/pharo/issues/detail?id=3436 "Au contraire" it does a *bit* to improve usability and as a consequence the readability. Blaming the need for a "a complete interface redesign" as a precondition to act is an invitation to remain pusillanimous and not change anything (a.k.a. "analysis paralisis"). IMO this move is small, but in the right direction. The main issue is that as the Object>>copyFrom: is being heavily used in production code, a planned way of doing this change has to be devised.

Jan. 5, 2011

Re: [Pharo-project] Alien and callbacks from "foreign" threads?

by Igor Stasenko

On 5 January 2011 21:40, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: > > > On Wed, Jan 5, 2011 at 11:58 AM, Igor Stasenko <siguctua(a)gmail.com> wrote: >> >> On 5 January 2011 20:07, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: >> > >> > >> > On Wed, Jan 5, 2011 at 10:36 AM, Igor Stasenko <siguctua(a)gmail.com> >> > wrote: >> >> >> >> I think any interoperability should have a reasonable limitations. >> >> Otherwise, there is no way how to guarantee the system stability. >> >> >> >> Squeak and Cog virtual machines can't run multiple native threads >> >> interpreting smalltalk code, which means that >> >> any callback(s) will be forced to be handled in single (VM) thread. >> > >> > No. Â One can arrange to shae the VM between native threads just like >> > Python, >> > which is what I've done in my prototype. >> > >> >> i didn't said it can't, i just don't see a reason for doing that. Too >> much for it. > > What do you mean "too much for it"? Â It costs too much? yes. too much for just 'callbacks'. I wouldn't bother about costs if it would be something bigger.. but if it just for callbacks, then its too much as to me. Don't take me wrong, it would be good to have: a thread-aware VM is step forward anyways :) > >> >> >> >> >> Apparently callbacks from foreign threads require a special checks to >> >> be added to detect it and then serialize the call to vm thread. >> > >> > No. Â One can arrange for the current thread to cede ownership to the >> > foreign >> > thread and allow it to run. Â With a two-evel scheduler one can still >> > arrange >> > to preserve Smalltalk process priorities and scheduling semantics. >> > Â Essentially one assigns a priority to foreign callbacks and they get to >> > run >> > as soon as their priority is high enough to displace the priority of the >> > current process (in whatever thread it may be). >> > The scheme you're describing is one I implemented in VisualWorks and it >> > is >> > slow and clumsy. Â The scheme I'm now using is due to David Simmons and >> > by >> > comparison is lightweight and fast. Â But neither are simple. >> > >> >> Sharing VM among multiple threads.. Okay.. but this is same. >> It doesn't eliminates a need of synchronizing with thread which >> currently 'owns' VM to obtain a control, >> which means you can't start handling callback immediately, that's why >> i told that it kills an idea of using multithreading. > > That doesn't follow. Â he fact you can't release the VM immediately doesn't > mean it can't happen very quickly, certainly quickly enough. Â Nothing > happens instantaneously in a computer. Â Computations take time. Thread > switches take time. Â But computers are fast. Â So I don't see that the idea > of using multithreading is killed at all. > Can VM handle two callbacks in parallel? No? Case closed :) I just don't like that in certain scenarios VM will serve as a lobotomizer for any external libraries, which invented a highly sophisticated ways to do multiple things at one time. I can hear a future woes and whines about 'why it sooo fast in X , but soo sloww smalltalk' :) And of course, for manycore era (which is yet-yet not happen), we have to propose something completely different, because given solution simply won't scale. But that of course affects many other systems and languages not just our beloved one :) >> >> Again, i hope you realizing that there is a lot of situations, where >> this won't go. >> Suppose that i using some library which using a thread-local storage. >> How i could guarantee that all calls to this library will be made in >> same thread, >> in situation, when VM could run interpreter in any random thread, >> resulted because of need to handle callback >> from other library, not related to one that used by code related to my >> library? > > Because my system allows one to bind a process to a specific thread so that > you can guarantee which thread a computation will run in by reserving a > process for that computation and binding it to the relevant thread. Â The > process scheduler (remember this is now a two-level scheduler) takes care of > switching threads when one switches processes. > That's not really solves the problem. Nothing prevents me from using same primitive(s) in different processes, which could lead to fatal error(s). Of course it is better than nothing.. But this will mean introducing some discipline into smalltalk code (and Debugger and Process etc etc) which is an added price, once you putting threaded callbacks into the cart, regardless whether you currently using them in your code or not. I wouldn't bother, but then again, seeing in what appalling state Squeak's own thread safety and scheduling is, i'd say it will take a loong road before we get to something stable out of it :) >> >> I don't see how it can be made 'automagically' without introducing an >> additional discipline in code, and without any >> notion of native threads at language side, where developer could >> enforce some rules, known by him. Otherwise an interoperability scheme >> which you introducing is mine field. > > If one has to interoperate with code that has threading constraints (such as > your example above) then one needs to code to those constraints. Â To be able > to code to those constraints there has to be some relevant mechanism. Â That > relevant mechanism is implementable (I have implemented it). Â But I don't > see what your argument is. Â The current non-threaded system doesn't provide > any way of interacting with foreign threads directly, right? Â So interacting > requires programming. Â Introducing threading into the VM makes things > easier, not more difficult, no? > It opens certain perspectives. Of course. About making things easier.. One good property of the concurrency mine-field, that its not magically disappears once you start using some pre-made uber-cool library. You either always following rules and write a concurrent code _everywhere_, or not.. and have an unwanted consequences. And any futile attempts to mask the complexity leads to even more frustration in the end :) >> Also, now Â you must check every single primitive which currently used >> by VM is thread safe, i.e. >> it can be invoked from any 'random' thread without leading to unwanted >> effect(s). Which is a good thing (oh and i did that in Hydra btw). > > Why? > you asking why its good? because if you know if prim (or perhaps plugin) is thread safe, then you can use it in any thread :) >> >> I know very well that some OS(es) and some libraries don't like when >> you using their functions either >> from non-main process thread, or from multiple threads. (Btw, Johm >> told scary story about GUI and multithreading on Macs multiple times >> ;) ) >> >> So, before introducing such kind of sharing , you should take care >> about every single >> primitive which using OS-specific function(s) or using some external >> library, that it is safe to make a calls >> from random thread. > > You certainly need to be able to control threading, yes. Â But you're being a > bit of a Cassandra. Â Â Most primitives are the VM's own and they work fine > whatever thread they're in. Â GUI activities can be restricted to the GUI > thread. Â FFI calls can be marked as threaded or non-threaded. Â Porcesses can > be bound to threads or free to run on any thread. Â So there's lots of > control. Â Â The system doesn't collapse into chaos as soon as one introduces > a thread. It doesn't collapse. Not at all. But it certainly becomes more brittle. Once (or if) you release the code, i will gladly show you some exploits, and of course would be happy if they won't break anything :) >> >> So, the question remains open: is it worth spending so much efforts >> for such small outcome? :) > > Small outcome? Â The ability to interact with multi-threaded libraries is a > small outcome? Â The ability to perform non-blocking calls is a small > outcome? Â We see things differently :) I meant just callbacks. For threaded calls i think i would just introduce a native threads control into language and let developer to instruct VM, from which thread do a certain call(s). That's much cheaper because it doesn't requires big changes from VM side. > best > Eliot -- Best regards, Igor Stasenko AKA sig.

Jan. 5, 2011

Re: [Pharo-project] Alien and callbacks from "foreign" threads?

by StÃ©phane Ducasse

eliot this sounds exciting. Explained what do you mean by prototype to joachim because it seems to me that he can be perfect beta tester :) > > > On Wed, Jan 5, 2011 at 10:36 AM, Igor Stasenko <siguctua(a)gmail.com> wrote: > I think any interoperability should have a reasonable limitations. > Otherwise, there is no way how to guarantee the system stability. > > Squeak and Cog virtual machines can't run multiple native threads > interpreting smalltalk code, which means that > any callback(s) will be forced to be handled in single (VM) thread. > > No. One can arrange to shae the VM between native threads just like Python, which is what I've done in my prototype. > > > Apparently callbacks from foreign threads require a special checks to > be added to detect it and then serialize the call to vm thread. > > No. One can arrange for the current thread to cede ownership to the foreign thread and allow it to run. With a two-evel scheduler one can still arrange to preserve Smalltalk process priorities and scheduling semantics. Essentially one assigns a priority to foreign callbacks and they get to run as soon as their priority is high enough to displace the priority of the current process (in whatever thread it may be). > > The scheme you're describing is one I implemented in VisualWorks and it is slow and clumsy. The scheme I'm now using is due to David Simmons and by comparison is lightweight and fast. But neither are simple. > > > > And therefore, handling callback in different thread will require a > synchronization with it, which kills an idea of > invoking callback from different thread in a first place. > > Nope. > > > So, even if Alien will implement support of callbacks in non-VM > thread(s), the value of such feature are questionable, > because it simply kills the attempt(s) of foreign language to gain > performance benefits through exploiting multithreading. > > I disagree. > > > Allowing to interpret smalltalk using multiple threads is another > story - see RoarVM :) > > That's not the only way to go. Python (and my Cog prototype) shares the VM amongst native threads and it is quite a lot simpler than implementing a concurrently-threaded VM. > > > So, unless you running RoarVM, i don't see that it is reasonable to > support cross-thread callbacks. > > Not at all. It's quite a reasonable thing to want to do, and is not beyond us. > > best > Eliot > > > -- > Best regards, > Igor Stasenko AKA sig. > >

Jan. 5, 2011

Re: [Pharo-project] [Moose-dev] Re: xmlsupport conflict in pharo 1.2

by Tudor Girba

Yes. He used the term correctly, because the decided titles were PharoCore for core, and Pharo for core+tools :) Cheers, Doru On 5 Jan 2011, at 23:12, StÃ©phane Ducasse wrote: > do you mean in Pharo-dev? > > On Jan 5, 2011, at 6:39 PM, Alexandre Bergel wrote: > >> I had a quick look at it. >> In Pharo 1.2, the XML-Parser parkage is clean (i.e.,not dirty). Loading XMLSupport turns the package dirty. The user is asked whether he is ready to lose his changes. I cannot determine why the packages turned dirty. >> >> Executing: >> Gofer new >> squeaksource: 'XMLSupport'; >> package: 'ConfigurationOfXMLSupport'; >> load. >> (Smalltalk at: #ConfigurationOfXMLSupport) perform: #loadDefault. >> >> in a fresh image raises the popup. Without canceling or accepting, open a Monticello browser, you will see the package dirty. >> >> Jaaryer, can you have a look at it? There is something weird with the configuration. I sincerely hope we will have a better tool for managing configuration. I am currently working on it, but it is still too early for releasing it. >> >> Cheers, >> Alexandre >> >> On 5 Jan 2011, at 11:41, Tudor Girba wrote: >> >>> Hi, >>> >>> XMLSupport is present in the latest Pharo 1.2. Loading a new version generates an exception apparently, so I removed for the moment XMLSupport from the default ConfigurationOfMoose. >>> >>> I think we should only load this conditionally. Or do you have another solution? >>> >>> Cheers, >>> Doru >>> >>> >>> -- >>> www.tudorgirba.com >>> >>> "Every thing should have the right to be different." >>> >>> >>> >>> >>> _______________________________________________ >>> Moose-dev mailing list >>> Moose-dev(a)iam.unibe.ch >>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >> >> -- >> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >> Alexandre Bergel http://www.bergel.eu >> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >> >> >> >> >> >> >> _______________________________________________ >> Moose-dev mailing list >> Moose-dev(a)iam.unibe.ch >> https://www.iam.unibe.ch/mailman/listinfo/moose-dev > > > _______________________________________________ > Moose-dev mailing list > Moose-dev(a)iam.unibe.ch > https://www.iam.unibe.ch/mailman/listinfo/moose-dev -- www.tudorgirba.com "Presenting is storytelling."

Jan. 5, 2011