Re: [Pharo-project] Pharo and CommandShell on OSX ?
On 5 January 2011 04:12, David T. Lewis wrote: > On Tue, Jan 04, 2011 at 08:03:42PM -0300, Esteban Lorenzano wrote: >> ah... I think (if I understood well) the real problem is that OSProcess >> were implementing it's own aio things and now it is relying (correctly) >> in AioPlugin... so, before that, it wasn't important if AioPlugin was >> present, and now it is (btw... UnixOSProcessPlugin don't really need >> AioPlugin, it switches to an ugly but necessary polling when absent) >> >> Cheers, >> Esteban > > Yes, that's right. The first version of OSProcess (from 1999) had > OSProcess and the OSProcessPlugin. Over time, it grew and I split > it into packages. Now CommandShell and OSProcess are the image side > packages, and OSProcessPlugin, AioPlugin, and XDisplayControlPlugin > provide the VM plugin support. All of it is written in Smalltalk, > including the plugins. > > Originally, CommandShell was part of OSProcess. And originally, > AioPlugin and XDisplayPlugin were part of OSProcessPlugin. > > CommandShell uses OSProcess (but loads and runs without it). > OSProcess uses mainly OSProcessPlugin, but also AioPlugin if > available. OSProcess also uses XDisplayControlPlugin when running > on X11, expecially to support #forkSqueak. > > The X window system is separate from the operating system, > therefore the XDisplayControlPlugin is separate from the > OSProcessPlugin. The aio functions are separate from the > operating system (they are part of Ian's Unix support code, > but not OS functions per se), so the AioPlugin is also separate > from the OSProcessPlugin. > What i have learned , that AioPlugin should be included in VM, so osprocess plugin will use more elegant way of working :) > At the higher level, things that relate directly to operating > system functions and to the representation of OS processes > are part of OSProcess. Things that relate to the pipes, unix > shell syntax, file name globbing, command line parsing, and > shell window display are part of CommandShell. > yes, but it is much nicer to use asynchronous IO for speaking with those pipes etc, than synchronous, because VM don't needs to be (b)locked each time. > Dave > > -- Best regards, Igor Stasenko AKA sig.
[Pharo-project] Monticello and source origin
When I create a changeset and file it out I can see the image (Pharo/Squeak and version) that was used to create the code in the header. Currently when I find an MCZ somewhere on the web I'm not able to see if Pharo 1.0 or Pharo 1.2 or Squeak 4.1 was used to create it. At least I havent found something when I check "package", "version", "snapshot.bin" or "snapshot"/source in the ZIP. Would'nt it make sense to add something like this? Thx Torsten -- Neu: GMX De-Mail - Einfach wie E-Mail, sicher wie ein Brief! Jetzt De-Mail-Adresse reservieren: http://portal.gmx.net/de/go/demail
Re: [Pharo-project] [Pharo-users] Minimal pharo
Hi all, Yes, I agree with Adrian, all cleanings should be integrated. Perhaps in #cleanUpForProduction that already integrates some elements pointed by Mariano. #Luc 2011/1/5 Adrian Lienhard > > On Jan 4, 2011, at 22:42 , Mariano Martinez Peck wrote: > > > ps: I wonder if any of those scripts should be added to ScriptLoader > > Yes, that would be good! Like this we can improve them and other people can > contribute. > > Esteban, could you share your experience with unloading packages? I assume > you had to also reorganize packages to make them cleanly unloadable? If yes > these changes should be integrated to improve the modularization. > > Cheers, > Adrian >
Re: [Pharo-project] Pharo and CommandShell on OSX ?
Ok a couple of years back Eliot had me compile up a AioPlugin for os-x I've send that to Esteban Lorenzano. I note that from a plugin perspective os-x is well unix. The os-x application loader code will either take a bundle or a library etc etc. it really doesn't care what form the binary is from pure ancient unix to post modern os-x bundle. Some people *think* os-x is special, well yes/no, it's is unix, yet the UI isn't x-windows so various things in osprocess won't fly, forking a UI based app freaks things out as it's ok for x-windows but that concept is lost on window server. Still the aioplugin as a bundle or dynlib, we don't care. On 2011-01-05, at 12:00 AM, Igor Stasenko wrote: > What i have learned , that AioPlugin should be included in VM, so > osprocess plugin will use more elegant way of working :) -- === John M. McIntoshTwitter: squeaker68882 Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com ===
Re: [Pharo-project] ConfigurationOfPharo: now with Mocketry, Autotest, XMLSupport and Helps
thanks laurent With Olivier auverlot friday we will take soup and use it as a casee study to write an help and a good structure. Stef On Jan 4, 2011, at 10:46 PM, laurent laffont wrote: > Hi, > > I've updated ConfigurationOfPharo 1.2-beta2: > Added: > - Mocketry > - XMLSupport > - Autotest > - Shortcuts-Help > > more tests and Help. > > I've put methods in categories. > > Can someone check ? > > For independent Help packages, shouldn't we create a ConfigurationOfPharoHelp > ? > > Cheers, > > Laurent Laffont > > Pharo Smalltalk Screencasts: http://www.pharocasts.com/ > Blog: http://magaloma.blogspot.com/
Re: [Pharo-project] Issue 3506 in pharo: TextMorph's #autoFit: and #wrapFlag: are confusing
thanks sean! On Jan 4, 2011, at 11:44 PM, Sean P. DeNigris wrote: > > Fix in inbox > SLICE-Issue-3506-TextMorphs-autoFit-and-wrapFlag-are-confusing-SeanDeNigris.1 > > Added comments for TextMorph's #autoFit: and #wrapFlag: > -- > View this message in context: > http://forum.world.st/Issue-3506-in-pharo-TextMorph-s-autoFit-and-wrapFlag-are-confusing-tp3174560p3174563.html > Sent from the Pharo Smalltalk mailing list archive at Nabble.com. >
Re: [Pharo-project] Generators for Pharo Xmax wish)
On Jan 4, 2011, at 11:43 PM, Ralph Boland wrote: > I earlier posted a Xmas wish that Pharo add generators > (steal the generators code from Squeak). > No one appeared to be familiar with them. > The generators code was added to Squeak by Andreas Raas. > The class Generator can be found in Squeak as a subclass > of Stream. It's about 140 lines of code and, as I said before, > is really useful and needed in order for me to port some of the > packages I am developing from Squeak to Pharo. > Class Generator is tested in class GeneratorTest which also serves > as examples of uses of Generators. > So please, someone go steal the code! Ralph please package it, open ticket, so that we have tracability. > And stealing is easy. We are not stealing we are reusing. And Generator are probably coming from GNU Smalltalk. > For example I stole the following comment on > class Generator directly from the class comment: > > " > A Generator transforms callback interfaces into stream interfaces. > > When a producer algorithm provide results as callbacks (blocks) and a > consumer algorithm expects streamable input, a Generator transforms > one into the other, for example: > > | generator | > generator := Generator on: [:g| Integer primesUpTo: 100 do:[:prime| g > yield: prime]]. > [generator atEnd] whileFalse:[Transcript show: generator next]. > " > > Regards, > > Ralph Boland >
Re: [Pharo-project] Generators for Pharo Xmax wish)
On Jan 5, 2011, at 8:55 AM, Noury Bouraqadi wrote: > Hi, > > Before integrating some code into Pharo the first step is to check that the > licence is MIT. from Squeak it is since they publish in MIT. Having tests and class comments would be a good check. > > Noury > On 5 janv. 2011, at 00:22, Miguel Cobá wrote: > >> The easiest way to get this code into pharo core is to create a mcz >> package, put it on PharoInbox on squeaksource and create a ticket in >> code.google.com/p/pharo referencing it and taggint it Fixed, this way >> Stéphane or Markus can harvest it to the core image. >> If the mcz package is overkill, then a simple fileout of the package in >> squeak attached to the ticket will do. >> >> Maybe in the long term a project on squeaksource should be created (if >> not exists) and new changes to to it and from there pulled to squeak and >> pharo. >> >> Cheers >> >> El mar, 04-01-2011 a las 15:43 -0700, Ralph Boland escribió: >>> I earlier posted a Xmas wish that Pharo add generators >>> (steal the generators code from Squeak). >>> No one appeared to be familiar with them. >>> The generators code was added to Squeak by Andreas Raas. >>> The class Generator can be found in Squeak as a subclass >>> of Stream. It's about 140 lines of code and, as I said before, >>> is really useful and needed in order for me to port some of the >>> packages I am developing from Squeak to Pharo. >>> Class Generator is tested in class GeneratorTest which also serves >>> as examples of uses of Generators. >>> So please, someone go steal the code! >>> And stealing is easy. For example I stole the following comment on >>> class Generator directly from the class comment: >>> >>> " >>> A Generator transforms callback interfaces into stream interfaces. >>> >>> When a producer algorithm provide results as callbacks (blocks) and a >>> consumer algorithm expects streamable input, a Generator transforms >>> one into the other, for example: >>> >>> | generator | >>> generator := Generator on: [:g| Integer primesUpTo: 100 do:[:prime| g >>> yield: prime]]. >>> [generator atEnd] whileFalse:[Transcript show: generator next]. >>> " >>> >>> Regards, >>> >>> Ralph Boland >>> >> >> -- >> Miguel Cobá >> http://twitter.com/MiguelCobaMtz >> http://miguel.leugim.com.mx >> >> >> >> > >
Re: [Pharo-project] Best way for change a window style
This is really good On Jan 5, 2011, at 2:18 AM, nullPointer wrote: > > Finally I implemented the posibility of create a custom windows in > CLFramework. > > The final visual result fails in somethings, but seems the original: > > http://forum.world.st/file/n3174741/example.png > > http://www.youtube.com/watch?v=QAu6fPyz1b0 > http://www.youtube.com/watch?v=Gb9NoWFdhXo > http://www.youtube.com/watch?v=5CpUnIH9KVw > -- > View this message in context: > http://forum.world.st/Best-way-for-change-a-window-style-tp3032341p3174741.html > Sent from the Pharo Smalltalk mailing list archive at Nabble.com. >
Re: [Pharo-project] Best way for change a window style
How do you save the ui once designed because I'm thinking that we could ask one of our guy here to help (implementing a kind of UIBuilder). Stef On Jan 5, 2011, at 2:18 AM, nullPointer wrote: > > Finally I implemented the posibility of create a custom windows in > CLFramework. > > The final visual result fails in somethings, but seems the original: > > http://forum.world.st/file/n3174741/example.png > > http://www.youtube.com/watch?v=QAu6fPyz1b0 > http://www.youtube.com/watch?v=Gb9NoWFdhXo > http://www.youtube.com/watch?v=5CpUnIH9KVw > -- > View this message in context: > http://forum.world.st/Best-way-for-change-a-window-style-tp3032341p3174741.html > Sent from the Pharo Smalltalk mailing list archive at Nabble.com. >
[Pharo-project] Hudson Win setup build
Would be nice if Hudson could also build the Pharo windows setup automatically in the future. Should be easy to setup. I know thats not the highest prio but I wanted to check if it is possible anyway (dont know what kind of machine the ci server is currently runnning on). Since I think VM's are built in the future via Hudson too there must be access to a win32 machine anyway. Thx T. -- NEU: FreePhone - kostenlos mobil telefonieren und surfen! Jetzt informieren: http://www.gmx.net/de/go/freephone
Re: [Pharo-project] Best way for change a window style
I don´t know if I understand correctly the question...
The design code is saved in a basic message #specmorph:
specMorph
| cLStatusbar container cLPanel |
"container"
container := CLPanel new.
self containerSpec: container.
container visible: false.
container openInWorld.
"cLPanel"
cLPanel := CLPanel new.
container addMorph: cLPanel.
self cLPanelSpec: cLPanel.
"cLStatusbar"
cLStatusbar := CLStatusbar new.
cLPanel addMorph: cLStatusbar.
self cLStatusbarSpec: cLStatusbar.
^container
and another spec method for define each control of view, in current example
be #cLPanelSpec:, #cLStatusbarSpec: and #containerSpec:, for example:
cLPanelSpec: aTCLControl
aTCLControl name: 'cLPanel'.
aTCLControl usePolymorphStyleMechanism: false.
aTCLControl balloonText: nil.
aTCLControl enabled: true.
aTCLControl location: 0...@0.
aTCLControl extent: 5...@377.
aTCLControl anchors: {true .true .true .true .}.
aTCLControl imageResource: nil.
aTCLControl style: {(BorderStyle width: 0 color: Color transparent)
.(Color
r: 0.892 g: 0.887 b: 0.879) .(Color r: 0.503 g: 0.553 b: 0.662) .false .true
.}.
aTCLControl minWidth: 2.
aTCLControl minHeight: 2.
aTCLControl layout: {ProportionalLayout .#spaceFill .#spaceFill .0
.false
.false .false .0 .0 .1073741823 .#topToBottom .#none .#center .#topLeft
.#topLeft .#none .#none .}.
I believe the definition of UI must be do with XUL, or XAML. Of that way
don´t need a designer in Smalltalk, else could be use some of tools for
create XAML o XUL uis. Later, a "Reader" could parse the XML and build a
Morphic GUI or a Seaside GUI.
Regards
--
View this message in context:
http://forum.world.st/Best-way-for-change-a-window-style-tp3032341p3175227.html
Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
Re: [Pharo-project] Hudson Win setup build
On Jan 5, 2011, at 11:11 AM, Torsten Bergmann wrote: > Would be nice if Hudson could also build > the Pharo windows setup automatically > in the future. Should be easy to setup. > > I know thats not the highest prio but > I wanted to check if it is possible anyway > (dont know what kind of machine the ci server > is currently runnning on). > right now we just have a linux slave builder. This is what IT Services was able to provide. > Since I think VM's are built in the future > via Hudson too there must be access to a > win32 machine anyway. Yes, we will look into setting up a Mac and a Windows slave soon. One idea is to use an older intel mac and install windows there as a virtual machine and use this machine for both windows and mac. Alternatively, Hudson can have Amazon E2C slaves... for windows, that would be an alternative (but an expensive one). Marcus -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD.
Re: [Pharo-project] Best way for change a window style
> I don´t know if I understand correctly the question...
Yes
> The design code is saved in a basic message #specmorph:
> specMorph
>
> | cLStatusbar container cLPanel |
> "container"
> container := CLPanel new.
> self containerSpec: container.
> container visible: false.
> container openInWorld.
>
> "cLPanel"
> cLPanel := CLPanel new.
> container addMorph: cLPanel.
> self cLPanelSpec: cLPanel.
>
> "cLStatusbar"
> cLStatusbar := CLStatusbar new.
> cLPanel addMorph: cLStatusbar.
> self cLStatusbarSpec: cLStatusbar.
>
> ^container
>
> and another spec method for define each control of view, in current example
> be #cLPanelSpec:, #cLStatusbarSpec: and #containerSpec:, for example:
>
> cLPanelSpec: aTCLControl
>
> aTCLControl name: 'cLPanel'.
> aTCLControl usePolymorphStyleMechanism: false.
> aTCLControl balloonText: nil.
> aTCLControl enabled: true.
> aTCLControl location: 0...@0.
> aTCLControl extent: 5...@377.
> aTCLControl anchors: {true .true .true .true .}.
> aTCLControl imageResource: nil.
> aTCLControl style: {(BorderStyle width: 0 color: Color transparent)
> .(Color
> r: 0.892 g: 0.887 b: 0.879) .(Color r: 0.503 g: 0.553 b: 0.662) .false .true
> .}.
> aTCLControl minWidth: 2.
> aTCLControl minHeight: 2.
> aTCLControl layout: {ProportionalLayout .#spaceFill .#spaceFill .0
> .false
> .false .false .0 .0 .1073741823 .#topToBottom .#none .#center .#topLeft
> .#topLeft .#none .#none .}.
ok this is better than to serialize the object.
> I believe the definition of UI must be do with XUL, or XAML. Of that way
> don´t need a designer in Smalltalk, else could be use some of tools for
> create XAML o XUL uis. Later, a "Reader" could parse the XML and build a
> Morphic GUI or a Seaside GUI.
As I told you before (read my previous emails) you do not need XML or XAML. You
just need what is done in VW a spec
They have done that and it works well. Here I did not formatted it well but you
GET EXACTLY THE SAME EXPRESSION POWER THAN XML
without the need for yet another parser.
> cLPanelSpec: aTCLControl
>
> aTCLControl name: 'cLPanel'.
> aTCLControl usePolymorphStyleMechanism: false.
> aTCLControl balloonText: nil.
> aTCLControl enabled: true.
> aTCLControl location: 0...@0.
> aTCLControl extent: 5...@377.
> aTCLControl anchors: {true .true .true .true .}.
> aTCLControl imageResource: nil.
> aTCLControl style: {(BorderStyle width: 0 color: Color transparent)
> .(Color
> r: 0.892 g: 0.887 b: 0.879) .(Color r: 0.503 g: 0.553 b: 0.662) .false .true
> .}.
> aTCLControl minWidth: 2.
> aTCLControl minHeight: 2.
> aTCLControl layout: {ProportionalLayout .#spaceFill .#spaceFill .0
> .false
> .false .false .0 .0 .1073741823 .#topToBottom .#none .#center .#topLeft
> .#topLeft .#none .#none .}.
can be turned into
#(Spec
name: 'cLPanel';
usePolymorphStyleMechanism: false;
...
and...)
this is strictly equivalent to XML. Now if you build an XML reader we will be
able to reuse the interpretation (oh there is this reference in the XML then
I should create an object of a specific class).
Look at the example below for the changeList widget. I do not have the time to
format it well.
#(#{UI.FullSpec} #window: #(#{UI.WindowSpec}
#label: #(#{Kernel.UserMessage} #key: #ChangeList #defaultString:
'Change List' #catalogID: #labels)
#min: #(#{Core.Point} 300 400) #bounds: #(#{Graphics.Rectangle} 512 268
942 768)
#menu: #menuBar #isEventDriven: true)
#component: #(#{UI.SpecCollection}
#collection: #(#(#{UI.SequenceViewSpec}
#properties:
#(#{UI.PropertyListDictionary} #dragOkSelector #wantToDrag: #dragEnterSelector
#dragEnter: #dragOverSelector #dragOver: #dragStartSelector #doDrag:
#dropSelector #drop: #dragExitSelector #dragLeave:)
#layout: #(#{Graphics.LayoutFrame} 0 0
0 0 -100 1 150 0)
#name: #listView
#model:
#selectionInList
#callbacksSpec:
#(#{UI.UIEventCallbackSubSpec} #doubleClickSelector:
#toggleRemoveForListController: #requestValueChangeSelector: #changeRequest)
#menu: #changeListMenuHolder) #(#{UI.CompositeSpecCollection} #collection:
#(#(#{UI.CheckBoxSpec} #layout: #(#{Core.Point} 4 0) #model: #fileFilterAdaptor
#label: #(#{Kernel.UserMessage} #key: #file #defaultString: 'file' #catalogID:
#labels)) #(#{UI.CheckBoxSpec} #layout: #(#{Core.Point} 4 25) #model:
#changeTypeFilterAdaptor #label: #(#{Kernel.UserMessage} #key: #type
#defaultString: 'type' #catalogID: #labels)) #(#{UI.CheckBoxSpec} #lay
Re: [Pharo-project] Best way for change a window style
First people should use it, second we should check if the code is overriding or not the code in the image (if this is the case we should see how the code in the kernel and in the builder should be changed to avoid overrides), Now you can load the package and use it. and this is the best move for pushing its adoption. I looked at the code long time ago and I should redo it. Stef On Jan 5, 2011, at 8:38 AM, Olivier Auverlot wrote: > uibuilder is a very impressive tool ! > > Pharo must have this type of tool for to be a credible solution in the > development of desktop applications.I think that integrate uibuilder in the > standard image will be a good idea :) > > this is planed ? > > Best regards > Olivier > www.auverlot.fr > >> Cool ! >> >> Laurent >> >> On Wed, Jan 5, 2011 at 2:18 AM, nullPointer wrote: >> >> Finally I implemented the posibility of create a custom windows in >> CLFramework. >> >> The final visual result fails in somethings, but seems the original: >> >> http://forum.world.st/file/n3174741/example.png >> >> http://www.youtube.com/watch?v=QAu6fPyz1b0 >> http://www.youtube.com/watch?v=Gb9NoWFdhXo >> http://www.youtube.com/watch?v=5CpUnIH9KVw >> -- >> View this message in context: >> http://forum.world.st/Best-way-for-change-a-window-style-tp3032341p3174741.html >> Sent from the Pharo Smalltalk mailing list archive at Nabble.com. >> >> > >
Re: [Pharo-project] Best way for change a window style
On 5 January 2011 10:07, Stéphane Ducasse wrote: > This is really good > +1 This is something, morphic was needed 10 years ago. Not saying about today. > On Jan 5, 2011, at 2:18 AM, nullPointer wrote: > >> >> Finally I implemented the posibility of create a custom windows in >> CLFramework. >> >> The final visual result fails in somethings, but seems the original: >> >> http://forum.world.st/file/n3174741/example.png >> >> http://www.youtube.com/watch?v=QAu6fPyz1b0 >> http://www.youtube.com/watch?v=Gb9NoWFdhXo >> http://www.youtube.com/watch?v=5CpUnIH9KVw >> -- >> View this message in context: >> http://forum.world.st/Best-way-for-change-a-window-style-tp3032341p3174741.html >> Sent from the Pharo Smalltalk mailing list archive at Nabble.com. >> > > > -- Best regards, Igor Stasenko AKA sig.
Re: [Pharo-project] Best way for change a window style
Yeah, that is dicussed before, many times. UIBuilder is dead, and I believe any type of classic designer like VW use. Try implement a classic designer for UIs is lost time. I have many time for lost :) I believe the future is WPF, and the tools for generate XAML. Too exists some tools for create XUL. Don´t is needed a UI designer in Smalltalk, only is needed a "Reader" for build the UI from a XML text. Regards. -- View this message in context: http://forum.world.st/Best-way-for-change-a-window-style-tp3032341p3175319.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
Re: [Pharo-project] Hudson Win setup build
On 5 January 2011 11:53, Marcus Denker wrote: > > On Jan 5, 2011, at 11:11 AM, Torsten Bergmann wrote: > >> Would be nice if Hudson could also build >> the Pharo windows setup automatically >> in the future. Should be easy to setup. >> >> I know thats not the highest prio but >> I wanted to check if it is possible anyway >> (dont know what kind of machine the ci server >> is currently runnning on). >> > > right now we just have a linux slave builder. This is what IT Services > was able to provide. > >> Since I think VM's are built in the future >> via Hudson too there must be access to a >> win32 machine anyway. > > > Yes, we will look into setting up a Mac and a Windows slave > soon. > > One idea is to use an older intel mac and install windows there > as a virtual machine and use this machine for both windows and mac. > > Alternatively, Hudson can have Amazon E2C slaves... for windows, that > would be an alternative (but an expensive one). > Well, let us try a cheapest alternative first :) First we need to build a working solution. Customizing or moving it somewhere else it won't be a big problem (i hope). As to me, one important thing is that community should be able to participate. Once it is done, it should stay open for improvements and additions/extensions by people from community no just a limited number of persons. Because obviously, none of us have time to watch for everything. > Marcus > > -- > Marcus Denker -- http://www.marcusdenker.de > INRIA Lille -- Nord Europe. Team RMoD. > -- Best regards, Igor Stasenko AKA sig.
Re: [Pharo-project] [Pharo-users] Minimal pharo
Hi, I don't think my experience is really usable for general image shrinking. What I was doing is preparing images to run on the iPhone, and then I was cutting a lot of things needed in any other scenarios. In fact, I named my "technic" as "brute shrinking" :P and what I was using was an adaptation of Pavel's experiments: 1) I run all the cleans provided on Pharo. 2) I change the morphic UI with a dummy one. 3) I remove lots of packages using package unloader (and I said: lots... any package I'm not using). 4) I remove lots of classes (again, any clearly not-used class remaining in not unloaded packages) 5) I remove lots of methods (using Pavel's listing, here) 6) finally I was removing even InputEventFetcher, etc. (no need for a iOS user interface, I'm processing the events in "other way") with all this, my smallest image were about 4.1M... and it was working properly inside an iPhone :) as you can see... it doesn't look like it is useful for real non-mars scenarios... I can provide the scripts, of course, if you still think it is useful. and I thought on reorganize, taking into account all this drops, yes... but the experiments were aborted by the apple clause change... now solved, but no time to continue the work on it yet :) Cheers, Esteban El 05/01/2011, a las 4:58a.m., Adrian Lienhard escribió: > > On Jan 4, 2011, at 22:42 , Mariano Martinez Peck wrote: > >> ps: I wonder if any of those scripts should be added to ScriptLoader > > Yes, that would be good! Like this we can improve them and other people can > contribute. > > Esteban, could you share your experience with unloading packages? I assume > you had to also reorganize packages to make them cleanly unloadable? If yes > these changes should be integrated to improve the modularization. > > Cheers, > Adrian
Re: [Pharo-project] [Pharo-users] Minimal pharo
Ah, I forgot to say the the general idea of my "brute shrinking" was opposite to Pavel's idea: Pavel's pharo kernel images is about to have a really tiny image and use that as a foundation to build major images. Mine is: having already a production image, I want to strip from image all things I'm not using, so my *final* image (not my starting image) is as small as possible. Cheers, Esteban El 05/01/2011, a las 4:58a.m., Adrian Lienhard escribió: > > On Jan 4, 2011, at 22:42 , Mariano Martinez Peck wrote: > >> ps: I wonder if any of those scripts should be added to ScriptLoader > > Yes, that would be good! Like this we can improve them and other people can > contribute. > > Esteban, could you share your experience with unloading packages? I assume > you had to also reorganize packages to make them cleanly unloadable? If yes > these changes should be integrated to improve the modularization. > > Cheers, > Adrian
[Pharo-project] Fwd: [Pharo-users] Smalltalk server pages
Begin forwarded message: > From: Annick Fron > Date: January 5, 2011 12:43:53 PM GMT+01:00 > To: A friendly place where any question about pharo is welcome > > Subject: [Pharo-users] Smalltalk server pages > Reply-To: A friendly place where any question about pharo is welcome > > > Hi, > > and in order to get a minimum of dynamic pages, (I think Seaside will be too > large for my memory) what is best to get simple Smalltalk server pages, > swazoo or Komhttpserver ? > > Annick Fron
Re: [Pharo-project] [Pharo-users] Minimal pharo
send code :) On Jan 5, 2011, at 9:16 AM, Luc Fabresse wrote: > Hi all, > > Yes, I agree with Adrian, all cleanings should be integrated. > Perhaps in #cleanUpForProduction that already integrates some elements > pointed by Mariano. > > #Luc > > > 2011/1/5 Adrian Lienhard > > On Jan 4, 2011, at 22:42 , Mariano Martinez Peck wrote: > > > ps: I wonder if any of those scripts should be added to ScriptLoader > > Yes, that would be good! Like this we can improve them and other people can > contribute. > > Esteban, could you share your experience with unloading packages? I assume > you had to also reorganize packages to make them cleanly unloadable? If yes > these changes should be integrated to improve the modularization. > > Cheers, > Adrian >
Re: [Pharo-project] Best way for change a window style
On Jan 5, 2011, at 12:38 PM, nullPointer wrote: > > Yeah, that is dicussed before, many times. > > UIBuilder is dead, and I believe any type of classic designer like VW use. > Try implement a classic designer for UIs is lost time. I have many time for > lost :) I do not think so but this is your right to think that > > I believe the future is WPF, and the tools for generate XAML. oh no. You mix the techno and the concept. Anyway when you will see that I'm right you will smile. > Too exists > some tools for create XUL. Don´t is needed a UI designer in Smalltalk, only > is needed a "Reader" for build the UI from a XML text. > > Regards. > -- > View this message in context: > http://forum.world.st/Best-way-for-change-a-window-style-tp3032341p3175319.html > Sent from the Pharo Smalltalk mailing list archive at Nabble.com. >
Re: [Pharo-project] ConfigurationOfPharo: now with Mocketry, Autotest, XMLSupport and Helps
> I've updated ConfigurationOfPharo 1.2-beta2: > Added: > - Mocketry > - XMLSupport > - Autotest > - Shortcuts-Help Cool! I also added MemoryMonitor I would be glad to hear what you would like to see as improvement Cheers, Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
Re: [Pharo-project] Best way for change a window style
On 5 January 2011 13:41, Stéphane Ducasse wrote: > > On Jan 5, 2011, at 12:38 PM, nullPointer wrote: > >> >> Yeah, that is dicussed before, many times. >> >> UIBuilder is dead, and I believe any type of classic designer like VW use. >> Try implement a classic designer for UIs is lost time. I have many time for >> lost :) > > I do not think so but this is your right to think that >> >> I believe the future is WPF, and the tools for generate XAML. > > oh no. You mix the techno and the concept. Anyway when you will see that I'm > right you will smile. > yes. please no WPF no XAML .. lets keep it simple.. just UI builder producing specs in smalltalk code >> Too exists >> some tools for create XUL. Don´t is needed a UI designer in Smalltalk, only >> is needed a "Reader" for build the UI from a XML text. >> >> Regards. >> -- >> View this message in context: >> http://forum.world.st/Best-way-for-change-a-window-style-tp3032341p3175319.html >> Sent from the Pharo Smalltalk mailing list archive at Nabble.com. >> > > > -- Best regards, Igor Stasenko AKA sig.
Re: [Pharo-project] Best way for change a window style
Le 05/01/2011 08:38, Olivier Auverlot a écrit : > uibuilder is a very impressive tool ! > > Pharo must have this type of tool for to be a credible solution in the > development of desktop applications.I think that integrate uibuilder in > the standard image will be a good idea :) Not everyone developer need a UI builder, however it should definitely load through a configuration. Hilaire -- Education 0.2 -- http://blog.ofset.org/hilaire
Re: [Pharo-project] Best way for change a window style
Looks neat. Last time I was told about UIBuilder it was closed, repository wiped out. Does it mean you changed your mind or something else conduct you to develop it? In curiosity. Hilaire Le 05/01/2011 02:18, nullPointer a écrit : > > Finally I implemented the posibility of create a custom windows in > CLFramework. > > The final visual result fails in somethings, but seems the original: > > http://forum.world.st/file/n3174741/example.png > > http://www.youtube.com/watch?v=QAu6fPyz1b0 > http://www.youtube.com/watch?v=Gb9NoWFdhXo > http://www.youtube.com/watch?v=5CpUnIH9KVw -- Education 0.2 -- http://blog.ofset.org/hilaire
Re: [Pharo-project] Issue 3436 in pharo: #copyFrom: is broken
Comment #10 on issue 3436 by sebastianconcept: #copyFrom: is broken http://code.google.com/p/pharo/issues/detail?id=3436 Well.. please ignore who said it, I don't care and you shouldn't be distracted with that, but we are looking at the problem right in the eye: "- It'll break code for no better reason than to increase readability" I don't recall seeing this so clearly. Here is the thing: every time that code usability is considered something "minor" or "wasteful" or "those things that stupid people needs" we are validating that smalltalk: 1. gives a shit about being intuitive 2. gives a shit about newcomers 3. of course shouldn't be mainstream. Every time. Why? Because if Jhon Noob the new developer can't do it (due to an absolutely irrelevant lack of readability) then he will feel excluded and his employer frustrated with the results and his boss tempted to blame the people who convinced him to work that project on smalltalk nobody but old-school people can deal with. It will not matter what we say or understand about it. Facts will talk by themselves in the eyes of other people. And if your plan is to force other people to understand you, then be honest with yourself: you are working to earn the shitty ranking position of your piece of software. So, really? is that what we want? Usability matters (and yes, not only at UI level). Deal with it. If you think that Smalltalk is suposed to be freaking good at that, then make it f* happen. PS: I'm not enjoying to write this cynical thing, but softy feedback is largely proven to be a #fail recipe
Re: [Pharo-project] Pharo and CommandShell on OSX ?
On Wed, Jan 05, 2011 at 09:00:41AM +0100, Igor Stasenko wrote: > On 5 January 2011 04:12, David T. Lewis wrote: > > On Tue, Jan 04, 2011 at 08:03:42PM -0300, Esteban Lorenzano wrote: > >> ah... I think (if I understood well) the real problem is that OSProcess > >> were implementing it's own aio things and now it is relying (correctly) > >> in AioPlugin... so, before that, it wasn't important if AioPlugin was > >> present, and now it is (btw... UnixOSProcessPlugin don't really need > >> AioPlugin, it switches to an ugly but necessary polling when absent) > >> > >> Cheers, > >> Esteban > > > > Yes, that's right. The first version of OSProcess (from 1999) had > > OSProcess and the OSProcessPlugin. Over time, it grew and I split > > it into packages. Now CommandShell and OSProcess are the image side > > packages, and OSProcessPlugin, AioPlugin, and XDisplayControlPlugin > > provide the VM plugin support. All of it is written in Smalltalk, > > including the plugins. > > > > Originally, CommandShell was part of OSProcess. And originally, > > AioPlugin and XDisplayPlugin were part of OSProcessPlugin. > > > > CommandShell uses OSProcess (but loads and runs without it). > > OSProcess uses mainly OSProcessPlugin, but also AioPlugin if > > available. OSProcess also uses XDisplayControlPlugin when running > > on X11, expecially to support #forkSqueak. > > > > The X window system is separate from the operating system, > > therefore the XDisplayControlPlugin is separate from the > > OSProcessPlugin. The aio functions are separate from the > > operating system (they are part of Ian's Unix support code, > > but not OS functions per se), so the AioPlugin is also separate > > from the OSProcessPlugin. > > > What i have learned , that AioPlugin should be included in VM, so > osprocess plugin will use more elegant way of working :) > > > At the higher level, things that relate directly to operating > > system functions and to the representation of OS processes > > are part of OSProcess. Things that relate to the pipes, unix > > shell syntax, file name globbing, command line parsing, and > > shell window display are part of CommandShell. > > > > yes, but it is much nicer to use asynchronous IO for speaking with > those pipes etc, than > synchronous, because VM don't needs to be (b)locked each time. Indeed, that is exactly how it works. AioPlugin provides the mechanism for IO event notification to processes in the image that handle the events, reading available data from a pipe in reponse to the IO event. Input file descriptors are set nonblocking (OSProcessPlugin) for input pipes, and the VM never blocks on input. If AioPlugin is not present, asynchronous IO notification is not available, so polling loops are used instead (but still with nonblocking input). In practice, you will not notice much difference between the polling and the asynchronous input approaches, but I do prefer the asynchronous handlers on aesthetic grounds ;) Dave
Re: [Pharo-project] [Pharo-users] Minimal pharo
Hi Esteban, Yes, I know... So, how do you do the shrinking? ;) Do you unload by package? If yes, are the remaining MC packages "clean" and there are no obsolete classes etc. in the resulting image? Cheers, Adrian On Jan 5, 2011, at 13:21 , Esteban Lorenzano wrote: > Ah, I forgot to say the the general idea of my "brute shrinking" was opposite > to Pavel's idea: Pavel's pharo kernel images is about to have a really tiny > image and use that as a foundation to build major images. Mine is: having > already a production image, I want to strip from image all things I'm not > using, so my *final* image (not my starting image) is as small as possible. > > Cheers, > Esteban > > El 05/01/2011, a las 4:58a.m., Adrian Lienhard escribió: > >> >> On Jan 4, 2011, at 22:42 , Mariano Martinez Peck wrote: >> >>> ps: I wonder if any of those scripts should be added to ScriptLoader >> >> Yes, that would be good! Like this we can improve them and other people can >> contribute. >> >> Esteban, could you share your experience with unloading packages? I assume >> you had to also reorganize packages to make them cleanly unloadable? If yes >> these changes should be integrated to improve the modularization. >> >> Cheers, >> Adrian >
Re: [Pharo-project] IRC meeting next Tuesday, January 4, at ...?
+1 Alexandre On 4 Jan 2011, at 19:10, laurent laffont wrote: > On Tue, Jan 4, 2011 at 10:04 PM, Stéphane Ducasse > wrote: > argh I totally missed my alarm clock on my machine (while cleaning the house > :) > So did people discuss? > May be we should redo a clear call. > > +1 > > > Laurent. > > > > Stef > > On Jan 3, 2011, at 9:46 PM, Adrian Lienhard wrote: > > > I just figured that I also can't make it tomorrow at 20:00 (I can be online > > 2 hours later, though). > > > > Anyway, I suggest that everybody who is interested to discuss and sync > > meets at 20:00 and it would be nice if somebody could write a short > > summary, which we can post to the mailing list and the website. > > > > BTW, the channel is #pharo-project on irc.freenode.net. If you don't have > > an IRC client you can browse to > > > > http://webchat.freenode.net/?channels=pharo-project > > > > Time: > > http://www.timeanddate.com/counters/customcounter.html?day=4&month=1&year=2011&hour=20&min=00&sec=00&p0=268 > > > > Cheers, > > Adrian > > > > > > > > On Jan 3, 2011, at 09:15 , Stéphane Ducasse wrote: > > > >> Thanks for the call adrian. I will be travelling until 16h (it was not > >> planned when I proposed that dat) but there is no problem, > >> Stef > >> On Jan 2, 2011, at 10:34 PM, Adrian Lienhard wrote: > >> > >>> Hi all, > >>> > >>> During the last meeting [1] we decided to do the next one on January 4 > >>> but we didn't decide when to start. > >>> > >>> The previous meeting started at 20:00 CET/UTC/GMT+1, which may not be > >>> optimal for people in other time zones. If somebody likes to suggest > >>> another time, please let us know soon! > >>> > >>> Cheers, > >>> Adrian > >>> > >>> [1] http://pharo-project.org/news?article=irc-meeting-notes > >> > >> > > > > > > > -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
Re: [Pharo-project] Issue 3436 in pharo: #copyFrom: is broken
Comment #11 on issue 3436 by step...@stack.nl: #copyFrom: is broken http://code.google.com/p/pharo/issues/detail?id=3436 The problem is that it clearly does nothing at all to improve readability and usability, as long as there is no consistent and complete interface. Without a complete interface redesign, this simply is no improvement.
[Pharo-project] Another Design Question - SOAP and WSDL - Subclass or not XMLElement
Hi there, While doing my experiments with SOAP and friends, I've come to the conclusion, I'll redo mainly SOAP because previous implementation is linked to an independent XML representation. I find XMLSupport very nice in design and well documented so I consider it as a basis for implementing SOAP (to me it's a really good example of package as they should be). But there come the design question. To me SOAP elements are particular XMLDocument and XMLElement. Indeed, I found the interfaces of java 6 which was quite what I have in mind [1]. I think the main problem (to me) is that XMLElement in Smalltalk has an inst var containing all children node. I think this is different in java. The consequence is to model SOAPEnvelope (subclass of XMLElement), I can't really add a body and header field respectively for the SOAPHeader and SOAPBody object. Instead I should put them in the children collection node. Is it a good practice ? Do I use a factory to ensure there's at least one and only one body and eventually a header ? Any other pattern for such situations ? Or would you avoid to subclass ? Secondary question: As I found this java API, I got really tempted to use a similar organization. It it authorized ? I couldn't really parse the license file :) Thanks in advance, Cédrick [1] http://download.oracle.com/javase/6/docs/api/javax/xml/soap/ <>
Re: [Pharo-project] Fwd: [Pharo-users] Smalltalk server pages
it depends what you call dynamic pages :) Personally, I'm in the way to develop a seaside app that will manage "customers" and whose main goal is to generate pure static html pages (which can be changed from the user interface - change mean modified where it's possible and interesting then generated again). Otherwise, I would look at ZnHTTP instead of Kom at least for HTTP Server. You could also have a look at Iliad or Aida which I think are less memory hungry than seaside (but to me, nothing beats pure html anyway with a fake dynamic impression ;) ). My 0.02c, > > > Begin forwarded message: > >> From: Annick Fron >> Date: January 5, 2011 12:43:53 PM GMT+01:00 >> To: A friendly place where any question about pharo is welcome >> >> Subject: [Pharo-users] Smalltalk server pages >> Reply-To: A friendly place where any question about pharo is welcome >> >> >> Hi, >> >> and in order to get a minimum of dynamic pages, (I think Seaside will be too >> large for my memory) what is best to get simple Smalltalk server pages, >> swazoo or Komhttpserver ? >> >> Annick Fron > >
Re: [Pharo-project] Another Design Question - SOAP and WSDL - Subclass or not XMLElement
On 5 January 2011 16:25, Cédrick Béler wrote: > Hi there, > > While doing my experiments with SOAP and friends, I've come to the > conclusion, I'll redo mainly SOAP because previous implementation is linked > to an independent XML representation. I find XMLSupport very nice in design > and well documented so I consider it as a basis for implementing SOAP (to me > it's a really good example of package as they should be). > > But there come the design question. To me SOAP elements are particular > XMLDocument and XMLElement. Indeed, I found the interfaces of java 6 which > was quite what I have in mind [1]. > > I think the main problem (to me) is that XMLElement in Smalltalk has an inst > var containing all children node. I think this is different in java. The > consequence is to model SOAPEnvelope (subclass of XMLElement), I can't really > add a body and header field respectively for the SOAPHeader and SOAPBody > object. Instead I should put them in the children collection node. > Is it a good practice ? Do I use a factory to ensure there's at least one and > only one body and eventually a header ? Any other pattern for such situations > ? hmm.. the existence if separate class for each of xml elements doesn't automatically means that it can validate a SOAP document that it is well formed, isn't? > Or would you avoid to subclass ? > > Secondary question: As I found this java API, I got really tempted to use a > similar organization. It it authorized ? I couldn't really parse the license > file :) > As to me, i'd better leave the xml domain as soon as possible by validating it and then parsing its elements into something, which is reification of actual SOAP query/response model , without trying to resemble an xml dom tree. > Thanks in advance, > > Cédrick > > [1] http://download.oracle.com/javase/6/docs/api/javax/xml/soap/ > > -- Best regards, Igor Stasenko AKA sig.
Re: [Pharo-project] Fwd: [Pharo-users] Smalltalk server pages
On 05 Jan 2011, at 16:34, Cédrick Béler wrote: > Otherwise, I would look at ZnHTTP instead of Kom at least for HTTP Server. > You could also have a look at Iliad or Aida which I think are less memory > hungry than seaside (but to me, nothing beats pure html anyway with a fake > dynamic impression ;) ). If you only need to build a couple of very simple HTML pages (say like for some embedded device) you could use Zn. It is very lightweight, both in the number of classes and in its dependencies. However, Seaside offers an enormeous amount of functionality that you will miss. You will have to generate HTML by hand for example. Sven
Re: [Pharo-project] Best way for change a window style
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.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
[Pharo-project] Alien and callbacks from "foreign" threads?
Hi everybody, I am close to releasing JNIPort (http://jniport.wikispaces.com) for Pharo and Squeak. Almost everything works on both Mac OS X and Windows with one exception. I can attach a Java VM to Pharo/Squeak, I can send messages to Java objects and get results back, and even callbacks from Java to Smalltalk seem to work. The exception is that a callback from Java to Smalltalk which comes from a different thread leads to a crash of the Squeak VM. I have not been able to figure out what the problem is. There is a similar problem with a hook of the Java VM: one can register a callback function which is called whenever the Java VM produces output for stdout/stderr. With Pharo 1.1.1 on Mac OS X, using this hook works when the hook contains a "nil halt", and if I simply proceed in each of the notifiers. When I remove the halt or replace it by a Delay, the image freezes. In Squeak 4.1 on Windows, the behavior is different: the VM crashes. Does Alien support callbacks coming from a "foreign" thread? Or is this a limitation of Alien? Thanks in advance for any help, Joachim Geidel -- View this message in context: http://forum.world.st/Alien-and-callbacks-from-foreign-threads-tp3175989p3175989.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
Re: [Pharo-project] Alien and callbacks from "foreign" threads?
Not really an answer to your question, but Dale Rogerson's Inside COM is an excellent book (a must-have on its own) that might help with such topics. I suspect what Alien will need to do is something similar to Apartment Threading - maybe it already does. It has (thankfully??) been a long time, but I vaguely recall mutterings about sequencing calls through the message queue, and even marshaling data and interface pointers across thread boundaries. Maybe Hydra holds some helpful answers?? If you have truly free threaded Java, it would probably be possible to get into situations where an Apartment threaded server would deadlock due to the synchronization of calls - I know enough to ask the question but not enough to answer it. I await an interesting discussion among the experts. From: pharo-project-boun...@lists.gforge.inria.fr [pharo-project-boun...@lists.gforge.inria.fr] On Behalf Of Joachim Geidel [joachim.gei...@onlinehome.de] Sent: Wednesday, January 05, 2011 12:22 PM To: pharo-project@lists.gforge.inria.fr Subject: [Pharo-project] Alien and callbacks from "foreign" threads? Hi everybody, I am close to releasing JNIPort (http://jniport.wikispaces.com) for Pharo and Squeak. Almost everything works on both Mac OS X and Windows with one exception. I can attach a Java VM to Pharo/Squeak, I can send messages to Java objects and get results back, and even callbacks from Java to Smalltalk seem to work. The exception is that a callback from Java to Smalltalk which comes from a different thread leads to a crash of the Squeak VM. I have not been able to figure out what the problem is. There is a similar problem with a hook of the Java VM: one can register a callback function which is called whenever the Java VM produces output for stdout/stderr. With Pharo 1.1.1 on Mac OS X, using this hook works when the hook contains a "nil halt", and if I simply proceed in each of the notifiers. When I remove the halt or replace it by a Delay, the image freezes. In Squeak 4.1 on Windows, the behavior is different: the VM crashes. Does Alien support callbacks coming from a "foreign" thread? Or is this a limitation of Alien? Thanks in advance for any help, Joachim Geidel -- View this message in context: http://forum.world.st/Alien-and-callbacks-from-foreign-threads-tp3175989p3175989.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
Re: [Pharo-project] Alien and callbacks from "foreign" threads?
Hi Joachim, On Wed, Jan 5, 2011 at 9:22 AM, Joachim Geidel wrote: > > Hi everybody, > > I am close to releasing JNIPort (http://jniport.wikispaces.com) for Pharo > and Squeak. Almost everything works on both Mac OS X and Windows with one > exception. I can attach a Java VM to Pharo/Squeak, I can send messages to > Java objects and get results back, and even callbacks from Java to > Smalltalk > seem to work. > > The exception is that a callback from Java to Smalltalk which comes from a > different thread leads to a crash of the Squeak VM. I have not been able to > figure out what the problem is. There is a similar problem with a hook of > the Java VM: one can register a callback function which is called whenever > the Java VM produces output for stdout/stderr. With Pharo 1.1.1 on Mac OS > X, > using this hook works when the hook contains a "nil halt", and if I simply > proceed in each of the notifiers. When I remove the halt or replace it by a > Delay, the image freezes. In Squeak 4.1 on Windows, the behavior is > different: the VM crashes. > > Does Alien support callbacks coming from a "foreign" thread? Or is this a > limitation of Alien? > That current version of Alien does /not/ support callbacks from foreign threads. I have a prototype that does support callbacks from foreign threasds and supports non-blocking callouts on arbitrary threads. Essentially the VM shares the VM between native threads such that only one thread can be running Smalltalk at any one time but that any number of natie thresds can share the VM. I demonstrated this to various people in Concepcíon during Smalltalks 2010. Are you interested in working with this prototype code? Pleaze let me know either way. I haven't sought permission to release this code yet but I would very much like to. I think there's value to Teleplace in my releasing it before we release it internally because it needs pounding on to bring up to production quality. If there's significant interest in this code I'll ask for permission to release it and see where we go from there. > Thanks in advance for any help, > Joachim Geidel > > -- > View this message in context: > http://forum.world.st/Alien-and-callbacks-from-foreign-threads-tp3175989p3175989.html > Sent from the Pharo Smalltalk mailing list archive at Nabble.com. > >
Re: [Pharo-project] Alien and callbacks from "foreign" threads?
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. Apparently callbacks from foreign threads require a special checks to be added to detect it and then serialize the call to vm thread. 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. 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. Allowing to interpret smalltalk using multiple threads is another story - see RoarVM :) So, unless you running RoarVM, i don't see that it is reasonable to support cross-thread callbacks. -- Best regards, Igor Stasenko AKA sig.
Re: [Pharo-project] Alien and callbacks from "foreign" threads?
Eliot Miranda-2 wrote: > > That current version of Alien does /not/ support callbacks from foreign > threads. > Aah, that explains a lot. ;-) Eliot Miranda-2 wrote: > > I have a prototype that does support callbacks from foreign > threasds and supports non-blocking callouts on arbitrary threads. > ... > Are you interested in working with this prototype code? Pleaze let me > know > either way. I haven't sought permission to release this code yet but I > would very much like to. I think there's value to Teleplace in my > releasing > it before we release it internally because it needs pounding on to bring > up > to production quality. If there's significant interest in this code I'll > ask for permission to release it and see where we go from there. > I'm not sure how many people will actually use JNIPort in Pharo or Squeak and need callbacks. Yes, I am interested, but given the small amount of time I have available for JNIPort, it may take some time until I can do something with your prototype. Also, JNIPort is currently just a hobby, and I will not use it in any kind of production software myself. I'm not sure if this qualifies as significant interest. ;-) Thanks! Joachim -- View this message in context: http://forum.world.st/Alien-and-callbacks-from-foreign-threads-tp3175989p3176173.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
Re: [Pharo-project] Alien and callbacks from "foreign" threads?
On Wed, Jan 5, 2011 at 10:36 AM, Igor Stasenko 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. > >
Re: [Pharo-project] Alien and callbacks from "foreign" threads?
Igor, Igor Stasenko wrote: > > So, unless you running RoarVM, i don't see that it is reasonable to > support cross-thread callbacks. > VisualWorks and Dolphin both support foreign callbacks, using two very different implementations. Yes, it's not easy, as there are lots of ways to create deadlocks and faults etc. Chris Uppal's implementation of JNIPort for Dolphin came with a highly complicated http://metagnostic.dolphinmap.net/JNIPort/threading.html mechanism for deadlock prevention which is now also part of the ports of JNIPort to VisualWorks, Pharo and Squeak. However, there are situations where foreign callbacks are needed simply because the external libraries which are used have a multithreaded implementation. E.g., the callbacks for monitoring a Java VM (to monitor class loading, garbage collection etc.) will always come from a foreign thread, and this has nothing to do with performance. It's just the way it is. Another example (see screenshot at the end of the page): http://metagnostic.dolphinmap.net/JNIPort/callback-example-1.html http://metagnostic.dolphinmap.net/JNIPort/callback-example-1.html Best regards, Joachim Geidel -- View this message in context: http://forum.world.st/Alien-and-callbacks-from-foreign-threads-tp3175989p3176215.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
Re: [Pharo-project] Alien and callbacks from "foreign" threads?
This is great news! Thanks a lot for your effort, Doru On 5 Jan 2011, at 18:22, Joachim Geidel wrote: > > Hi everybody, > > I am close to releasing JNIPort (http://jniport.wikispaces.com) for Pharo > and Squeak. Almost everything works on both Mac OS X and Windows with one > exception. I can attach a Java VM to Pharo/Squeak, I can send messages to > Java objects and get results back, and even callbacks from Java to Smalltalk > seem to work. > > The exception is that a callback from Java to Smalltalk which comes from a > different thread leads to a crash of the Squeak VM. I have not been able to > figure out what the problem is. There is a similar problem with a hook of > the Java VM: one can register a callback function which is called whenever > the Java VM produces output for stdout/stderr. With Pharo 1.1.1 on Mac OS X, > using this hook works when the hook contains a "nil halt", and if I simply > proceed in each of the notifiers. When I remove the halt or replace it by a > Delay, the image freezes. In Squeak 4.1 on Windows, the behavior is > different: the VM crashes. > > Does Alien support callbacks coming from a "foreign" thread? Or is this a > limitation of Alien? > > Thanks in advance for any help, > Joachim Geidel > > -- > View this message in context: > http://forum.world.st/Alien-and-callbacks-from-foreign-threads-tp3175989p3175989.html > Sent from the Pharo Smalltalk mailing list archive at Nabble.com. > -- www.tudorgirba.com "Being happy is a matter of choice."
Re: [Pharo-project] Best way for change a window style
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 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.html > Sent from the Pharo Smalltalk mailing list archive at Nabble.com. > >
Re: [Pharo-project] Alien and callbacks from "foreign" threads?
On 5 January 2011 20:07, Eliot Miranda wrote: > > > On Wed, Jan 5, 2011 at 10:36 AM, Igor Stasenko 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 >
Re: [Pharo-project] Best way for change a window style
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
Re: [Pharo-project] Best way for change a window style
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.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
[Pharo-project] [ANN] Amazon AWS S3 Client
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.
Re: [Pharo-project] Alien and callbacks from "foreign" threads?
On Wed, Jan 5, 2011 at 11:58 AM, Igor Stasenko wrote: > On 5 January 2011 20:07, Eliot Miranda wrote: > > > > > > On Wed, Jan 5, 2011 at 10:36 AM, Igor Stasenko > 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 thre
[Pharo-project] about cleaning undo
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
Re: [Pharo-project] Best way for change a window style
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
[Pharo-project] Origins [poll]
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
[Pharo-project] Issue 3507 in pharo: SUnitUnloader >> unloadTestPackages is wrong and outdated
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
Re: [Pharo-project] Best way for change a window style
Catalunya, y tú seguro que eres Argentino XD -- View this message in context: http://forum.world.st/Best-way-for-change-a-window-style-tp3032341p3176514.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
[Pharo-project] why (MCPackage named: 'NonExistenPackage') unload. doesnt fail ?
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
[Pharo-project] Issue 3508 in pharo: cleanUpForProduction should really unload 'Graphics-Resources'
Status: Accepted Owner: marianopeck Labels: Milestone-1.2 New issue 3508 by marianopeck: cleanUpForProduction should really unload 'Graphics-Resources' http://code.google.com/p/pharo/issues/detail?id=3508 now cleanUpForProduction is doing: (MCPackage named: 'GraphicsResources') unload. but the package doesn't exist. So, it should be: (MCPackage named: 'Graphics-Resources') unload. Pharo core version: 12292
Re: [Pharo-project] Issue 3508 in pharo: cleanUpForProduction should really unload 'Graphics-Resources'
Updates: Status: Fixed Comment #1 on issue 3508 by marianopeck: cleanUpForProduction should really unload 'Graphics-Resources' http://code.google.com/p/pharo/issues/detail?id=3508 (No comment was entered for this change.)
Re: [Pharo-project] Pharo and CommandShell on OSX ?
On Jan 4, 2011, at 11:59 PM, Esteban Lorenzano wrote: > he, we already have something A LOT better: Filesystem. I would like it to > become the default Pharo file manager :( yes this is the idea. Now I should check that colin merge the fixes of lukas and get an update about the streams dependencies. >
Re: [Pharo-project] Issue 3507 in pharo: SUnitUnloader >> unloadTestPackages is wrong and outdated
Updates: Status: Fixed Comment #1 on issue 3507 by marianopeck: SUnitUnloader >> unloadTestPackages is wrong and outdated http://code.google.com/p/pharo/issues/detail?id=3507 (No comment was entered for this change.)
Re: [Pharo-project] about cleaning undo
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? no, this because CommandHistory is deprecated an not used anymore. Before, a global history was used to store commands for morphic (in worldstate maybe, I'm not sure). in such case, there insn't anything to be cleaned ? editor undo commands are stored locally. So, when you close an editor, no command remain. cheers Alain thanks mariano
Re: [Pharo-project] [ANN] Amazon AWS S3 Client
Thanks :) Stef On Jan 5, 2011, at 9:36 PM, Sven Van Caekenberghe wrote: > 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. > > >
Re: [Pharo-project] about cleaning undo
Excellent :) I was sure you didn't forget anything, but I was curious about why you didn't need a clean. Thanks Alain for the explanation. Mariano On Wed, Jan 5, 2011 at 11:12 PM, Alain Plantec wrote: > 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? >> > no, this because CommandHistory is deprecated an not used anymore. Before, > a global history was used to store commands for morphic (in worldstate > maybe, I'm not sure). > > in such case, there insn't anything to be cleaned ? >> > editor undo commands are stored locally. So, when you close an editor, no > command remain. > cheers > Alain > >> >> thanks >> >> mariano >> > > >
Re: [Pharo-project] Alien and callbacks from "foreign" threads?
JNIport is important for us. We should get a better interoperability with Java so that we can integrate instead of been rejected. Joachin your work is ***important***. Stef On Jan 5, 2011, at 7:54 PM, Joachim Geidel wrote: > > > Eliot Miranda-2 wrote: >> >> That current version of Alien does /not/ support callbacks from foreign >> threads. >> > > Aah, that explains a lot. ;-) > > > Eliot Miranda-2 wrote: >> >> I have a prototype that does support callbacks from foreign >> threasds and supports non-blocking callouts on arbitrary threads. >> ... >> Are you interested in working with this prototype code? Pleaze let me >> know >> either way. I haven't sought permission to release this code yet but I >> would very much like to. I think there's value to Teleplace in my >> releasing >> it before we release it internally because it needs pounding on to bring >> up >> to production quality. If there's significant interest in this code I'll >> ask for permission to release it and see where we go from there. >> > > I'm not sure how many people will actually use JNIPort in Pharo or Squeak > and need callbacks. Yes, I am interested, but given the small amount of time > I have available for JNIPort, it may take some time until I can do something > with your prototype. Also, JNIPort is currently just a hobby, and I will not > use it in any kind of production software myself. I'm not sure if this > qualifies as significant interest. ;-) > > Thanks! > Joachim > > -- > View this message in context: > http://forum.world.st/Alien-and-callbacks-from-foreign-threads-tp3175989p3176173.html > Sent from the Pharo Smalltalk mailing list archive at Nabble.com. >
Re: [Pharo-project] [Moose-dev] Re: xmlsupport conflict in pharo 1.2
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-...@iam.unibe.ch >>> https://www.iam.unibe.ch/mailman/listinfo/moose-dev >> >> -- >> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >> Alexandre Bergel http://www.bergel.eu >> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >> >> >> >> >> >> >> ___ >> Moose-dev mailing list >> moose-...@iam.unibe.ch >> https://www.iam.unibe.ch/mailman/listinfo/moose-dev > > > ___ > Moose-dev mailing list > moose-...@iam.unibe.ch > https://www.iam.unibe.ch/mailman/listinfo/moose-dev -- www.tudorgirba.com "Presenting is storytelling."
Re: [Pharo-project] Alien and callbacks from "foreign" threads?
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 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. > >
Re: [Pharo-project] Alien and callbacks from "foreign" threads?
On 5 January 2011 21:40, Eliot Miranda wrote: > > > On Wed, Jan 5, 2011 at 11:58 AM, Igor Stasenko wrote: >> >> On 5 January 2011 20:07, Eliot Miranda wrote: >> > >> > >> > On Wed, Jan 5, 2011 at 10:36 AM, Igor Stasenko >> > 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
Re: [Pharo-project] Issue 3436 in pharo: #copyFrom: is broken
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.
Re: [Pharo-project] Origins [poll]
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.c...@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
Re: [Pharo-project] why (MCPackage named: 'NonExistenPackage') unload. doesnt fail ?
Joining the canvassing campaign done by Bill: *by all means, please, NO!* -- Cesar Rabak Em 05/01/2011 19:53, Mariano Martinez Peck < marianop...@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
Re: [Pharo-project] Origins [poll]
;) 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, csra...@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.c...@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
Re: [Pharo-project] Origins [poll]
2011/1/5 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 Germán Arduino|Spanish|Hola|Argentina|Sunchales, Argentina :)
Re: [Pharo-project] Origins [poll]
> Name|Native Language|Greeting in native lang|Born country|Writing from I would like to add some keywords of my interests: Alexandre Bergel | French | Bonjour | France | Chile | software quality, code profiling, visualization, moose Alexandre > > Miguel Cobá|Spanish|Hola|Mexico|Mexico City,Mexico > > Cheers > -- > Miguel Cobá > http://twitter.com/MiguelCobaMtz > http://miguel.leugim.com.mx > > > > -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
Re: [Pharo-project] Origins [poll]
Tony Fleig|English (well, American English)|Yo|USA|California, USA TF On Wed, Jan 5, 2011 at 1:38 PM, Miguel Cobá wrote: > 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 > > > > >
Re: [Pharo-project] controlling the size of a morph embedded in a morphtreemorph
Hi Doru, I know it's a problem with morphtreemorph. I will have a look. Chers Alain 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."
Re: [Pharo-project] Alien and callbacks from "foreign" threads?
Igor Stasenko wrote: > > 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' :) > Igor, there are cases where foreign callbacks are needed and where this has nothing at all to do with performance or multi-core processors. I have already pointed out the case of monitoring a Java VM from a Smalltalk application which uses Java libraries. In this case, it's completely irrelevant what the performance is or whether the Smalltalk VM can handle two callbacks in parallel. Best regards, Joachim Geidel -- View this message in context: http://forum.world.st/Alien-and-callbacks-from-foreign-threads-tp3175989p3176980.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.
