- Pharo-dev - lists.pharo.org

[Pharo-project] Issue 3507 in pharo: SUnitUnloader >> unloadTestPackages is wrong and outdated

by pharo＠googlecode.com

Status: Accepted Owner: marianopeck Labels: Milestone-1.2 New issue 3507 by marianopeck: SUnitUnloader >> unloadTestPackages is wrong and outdated http://code.google.com/p/pharo/issues/detail?id=3507 SUnitUnloader >> unloadTestPackages is wrong because it uses # instead of ''. This fails with packages like 'Gofer-Tests'. In addition, this list is not updated. Now, cleanUpForProduction saves 100kb more aprox ;) Pharo core version: 12992 The change is to change unloadTestPackages to: unloadTestPackages #('Tests' 'CollectionsTests' 'CompilerTests' 'FreeTypeTests' 'Graphics-Tests' 'KernelTests' 'MorphicTests' 'MultilingualTests' 'NetworkTests' 'ToolsTest' 'Gofer-Tests' 'Announcements-Tests-Core' 'CompressionTests' 'HelpSystem-Tests' 'Multilingual-Tests' 'Regex-Tests-Core') do: [ :each | (MCPackage named: each) unload ]. if you agree I create a slice

Jan. 5, 2011

[Pharo-project] Origins [poll]

by Miguel CobÃ¡

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] Best way for change a window style

by Miguel CobÃ¡

PensÃ© que inglÃ©s era tu idioma nativo. Y como nullpointer no es un nombre normal en ningÃºn paÃs conocido ;) no tenÃa manera de saber que hablabas espaÃ±ol. Â¿De dÃ³nde eres? El miÃ©, 05-01-2011 a las 12:16 -0800, nullPointer escribiÃ³: > Mi inglÃ©s es penoso. Lo que quiero decir es que aunque haya un proyecto en > SourceSafe llamado UIBuilder, que es exactamente igual al CLFramework, lo > Ãºnico que he modificado son clases que no tienen nada que ver con aquellas > categorÃas relacionadas con el diseÃ±ador de UIs. El desarrollo del diseÃ±ador > de interfaces esta cerrado desde hace tiempo y yo al menos no lo voy a > continuar. > > > Google translation - My English is poor. What I mean is that even if a > project called UIBuilder SourceSafe, which is exactly equal to CLFramework > only thing I changed are classes that have nothing to do with those > categories related to the designer of UIs. The development of the interface > designer is closed for some time and I for one am not going to continue. -- Miguel CobÃ¡ http://twitter.com/MiguelCobaMtz http://miguel.leugim.com.mx

Jan. 5, 2011

[Pharo-project] about cleaning undo

by Mariano Martinez Peck

Hi alain. In #cleanUpForRelease of Pharo 1.1 we did at some point a Smalltalk cleanUpUndoCommands. Now in pharo 1.2 this is removed. I guess it is because of the new undo framework? in such case, there insn't anything to be cleaned ? thanks mariano

Jan. 5, 2011

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

by Eliot Miranda

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? > > >> > >> 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. > > > 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. > > 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? 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? > > 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. > 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 :) best Eliot > > > >> > >> 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. > > > > access to VM run-time are obviosly synchronous. And as long as it true, > there is very small reason to use multiple threads. > > A simple example. Suppose you using a 3rd party library for setting up > a socket server, which is a single call, accepting a pointer to > function > which will handle incoming connections. The external library takes > care about rest itself: it using thread pool(s) for incoming > connections > and in this way distributing load among multiple native threads. > Now, what will happen if you pass a smalltalk callback to it? > > I can elaborate that, but i think you know it yourself. > > >> > >> 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. > > sure its simpler. but kills multithreading benefits :) > > >> > >> 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. > > Yeah, it is painful to turn once non-thread aware VM into be thread > aware and play nicely with other players on [mine] field :) > > > best > > Eliot > > > >> > >> -- > >> Best regards, > >> Igor Stasenko AKA sig. > >> > > > > > > > > -- > Best regards, > Igor Stasenko AKA sig. > >

Jan. 5, 2011

[Pharo-project] [ANN] Amazon AWS S3 Client

by Sven Van Caekenberghe

Hi All, I implemented and published a Pharo client for Amazon's AWS S3 service called ZnAWSS3Client. For some background, see http://en.wikipedia.org/wiki/Amazon_S3 or http://aws.amazon.com/s3. The code can be found in the package 'Zinc-AWS' in http://www.squeaksource.com/ZincHTTPComponents.html. It depends on both Zinc HTTP Components and XML Support (an excellent package BTW) as well as on the cryptography functionality in Pharo (md5, sha1 & hmac). Basically, Amazon S3 (Simple Storage Service) is an online storage web service where you store and retrieve objects under keys organized in groups called buckets. Objects can be any web resource identified by a mime type. The main advantage is that S3 is a highly scalable, reliable, secure, fast, inexpensive service. The client is currently a proof of concept implementing the basic S3 concepts. Here is some example usage: | client | (client := ZnAWSS3Client new) accessKeyId: '2ZGSSBGBHQGJ9VV5N441'; secretAccessKey: 'OtxrzxIsfpFjA7SwPzILwy8Bw21TLhquhboDYROV'; checkIntegrity: true. client buckets. client keysIn: 'my-bucket'. client keysIn: 'my-bucket' query: (Dictionary with: 'prefix'->'my-'). client at: 'my-bucket' -> 'my-key'. client at: 'my-bucket' -> 'my-key' put: (ZnEntity with: '0123456789'). client at: 'my-bucket' -> 'my-key' put: (ZnEntity with: 'Smalltalk rules S3!') headers: (Dictionary with: 'x-amz-acl'->'public-read'). Sven PS: the code does contain comments but you will need to read up on S3 first. To run anything you will have to create an AWS S3 account.

Jan. 5, 2011

Re: [Pharo-project] Best way for change a window style

by nullPointer

Mi inglÃ©s es penoso. Lo que quiero decir es que aunque haya un proyecto en SourceSafe llamado UIBuilder, que es exactamente igual al CLFramework, lo Ãºnico que he modificado son clases que no tienen nada que ver con aquellas categorÃas relacionadas con el diseÃ±ador de UIs. El desarrollo del diseÃ±ador de interfaces esta cerrado desde hace tiempo y yo al menos no lo voy a continuar. Google translation - My English is poor. What I mean is that even if a project called UIBuilder SourceSafe, which is exactly equal to CLFramework only thing I changed are classes that have nothing to do with those categories related to the designer of UIs. The development of the interface designer is closed for some time and I for one am not going to continue. -- View this message in context: http://forum.world.st/Best-way-for-change-a-window-style-tp3032341p3176337.… Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

Jan. 5, 2011

Re: [Pharo-project] Best way for change a window style

by Hilaire Fernandes

Le 05/01/2011 18:19, nullPointer a Ã©crit : > > CLFramework continues in develop but donÂ´t the subset UIBuilder. For the > change of window styles I didnÂ´t almost update UIBuilder. > > Regards. I don't understand. Hilaire

Jan. 5, 2011

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

by Igor Stasenko

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. >> >> 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. 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? 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. 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). 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. So, the question remains open: is it worth spending so much efforts for such small outcome? :) >> >> 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. > access to VM run-time are obviosly synchronous. And as long as it true, there is very small reason to use multiple threads. A simple example. Suppose you using a 3rd party library for setting up a socket server, which is a single call, accepting a pointer to function which will handle incoming connections. The external library takes care about rest itself: it using thread pool(s) for incoming connections and in this way distributing load among multiple native threads. Now, what will happen if you pass a smalltalk callback to it? I can elaborate that, but i think you know it yourself. >> >> 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. sure its simpler. but kills multithreading benefits :) >> >> 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. Yeah, it is painful to turn once non-thread aware VM into be thread aware and play nicely with other players on [mine] field :) > best > Eliot > >> >> -- >> Best regards, >> Igor Stasenko AKA sig. >> > > -- Best regards, Igor Stasenko AKA sig.

Jan. 5, 2011

Re: [Pharo-project] Best way for change a window style

by Mariano Martinez Peck

WHich is the difference between CLFramework and UIBUilder? I thought it was the same.... gracias! mariano On Wed, Jan 5, 2011 at 6:19 PM, nullPointer <epicfan(a)gmail.com> wrote: > > CLFramework continues in develop but donÂ´t the subset UIBuilder. For the > change of window styles I didnÂ´t almost update UIBuilder. > > Regards. > -- > View this message in context: > http://forum.world.st/Best-way-for-change-a-window-style-tp3032341p3175983.… > Sent from the Pharo Smalltalk mailing list archive at Nabble.com. > >

Jan. 5, 2011