- Pharo-dev - lists.pharo.org

Re: [Pharo-project] Pharo 1.4 and Zodiac

by Henrik Sperre Johansen

On 27.06.2012 20:37, Igor Stasenko wrote: > On 27 June 2012 16:38, Sven Van Caekenberghe <sven(a)beta9.be> wrote: >> On 27 Jun 2012, at 16:21, Henrik Sperre Johansen wrote: >> >>> Well, there's for sure no SqueakSSL so's or dll's in the downloads. >>> I assumed it might be set to build as internal, in which case it doesn't seem to be working as intended (at least on Windows) >> It is there the latest Mac OS and Linux VM's, but indeed not in the Windows VM. >> > Right, we got SSL only for mac and linux. > For windows, AFAIK someone told that it has never worked. I think if > you search mailing list archive for "SSL and windows" you will find it > quickly. The compiled .dll Sven linked worked just fine, so *someone* must have gotten it working :) > The work i did with bundling 3rd party libs with VMs actually opens a > good opportunity to fix that in future > (we could DL/compile windows version of OpenSSL library and then > corresponding plugin).. > but that is something which has to be done in future. Maybe it's just me, but I find having it available on all platforms is sort of a nice thing before including it in a release, at least when there's no non-plugin fallback code. Cheers, Henry

June 28, 2012

Re: [Pharo-project] MCSqueaksourceRepository

by Sean P. DeNigris

Camillo Bruni-3 wrote > > That was a quick hack to support a decent menu item entry when adding a > repository. > Well, it's not necessarily a bad design. If we can keep them, I'd like to add class inst vars to MCHttpRepository for user and password, so we can supply credentials to be used for each ss3/ss/etc... Sean -- View this message in context: http://forum.world.st/MCSqueaksourceRepository-tp4636737p4637040.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

June 28, 2012

[Pharo-project] VM , modules, packages and plugins

by Torsten Bergmann

>What i would like to see one day is when i installing new code into >image, it pops up a message: >"Your VM missing an XYZ plugin for running this cool code, would you >like to download and install it? Yes No " The first problem is that there is no consolidated way to find the plugins. Or am I'm missing something. Remember this: http://code.google.com/p/pharo/wiki/VMPluginOverview http://web.archiveorange.com/archive/v/omFiNcYAwvI6GB8z7r1j As ever it is a question of time to define and implement a working process. Bye T. -- NEU: FreePhone 3-fach-Flat mit kostenlosem Smartphone! Jetzt informieren: http://mobile.1und1.de/?ac=OM.PW.PW003K20328T7073a

June 28, 2012

Re: [Pharo-project] VM , modules, packages and plugins

by Schwab,Wilhelm K

I agree, except for silent updates. One should at know what is happening, and further be able to run a "broken" mixture, if only for debugging. ________________________________________ From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] on behalf of Igor Stasenko [siguctua(a)gmail.com] Sent: Wednesday, June 27, 2012 6:48 PM To: Pharo Development Subject: [Pharo-project] VM , modules, packages and plugins Seeing another thread about "is XYZ plugin there or not" or "what may cause prim fail" i REALLY suggest that we should stop and think.. This plugin's usage logic is inherently flawed.. (or i would say outdated) What i would like to see one day is when i installing new code into image, it pops up a message: "Your VM missing an XYZ plugin for running this cool code, would you like to download and install it? Yes No " In case of Pharo, we should really start thinking about delivering quality grade solutions, not something which might work if you properly jump 2 times and whistle 7 times while faced North"... Look at what the practices which become common today in modern browsers, and OSes - they updating themselves without a notice and just asking you to restart it time to time. Why we cannot do the same? -- Best regards, Igor Stasenko.

June 28, 2012

Re: [Pharo-project] Pharo and Namespaces

by Igor Stasenko

I want to second Stef's word. Coming from C++ world with namespaces at some point i felt like i really miss that. But my practice shows that what i miss is not a mere syntactic sugar or tool support of having multiple namespaces. No. What i miss is the true modular system, where modules are first-class components of it and know how to connect and interact between each other. If you look at the problem at this angle, you will see that being able to define own binding of some name(s) local to the module scope is just a tiny bit of a larger picture. -- Best regards, Igor Stasenko.

June 27, 2012

Re: [Pharo-project] Pharo and Namespaces

by Igor Stasenko

Late binding, yes. But please stop using "Global" word :) The Global word pins you to a little piece of dust floating in gazillion times bigger space. Think about it every time you think you found solution, which requires having some "global" state/functionality in your model. :) On 27 June 2012 19:47, Jan Vrany <jan.vrany(a)fit.cvut.cz> wrote: > On 27/06/12 18:05, Sean P. DeNigris wrote: >> >> >> GermÃ¡n Leiva wrote >>> >>> >>> OT: Late binding rocks! >>> >> >> Yes, and the latest binding would be to lookup at runtime. I have no idea >> what the performance hit would be, or if we would use all that power, but >> the idea is exciting :) > > > With proper caching at VM level, the performance overhead would be > negligible. > > Typically, when a class is accessed, something like PUSH_GLOBAL insn > is generated. One may change semantics of this insns to do a proper > message send back, effectively doing something like (for instance) > Â self class resolveGlobalByName: globalName > > This is very flexible and allows for very nice tricks. > > This can be further performance-optimized. One may use a sort of an inline > Â cache keeping a pair - function pointer to a function that > returns desired value and a "cached data". > Initially, the function would be initialized to a function that calls back > smalltalk code like the one above. However, the smalltalk > code __may__ decide that the resolution is "stable" (i.e., next time the > code runs, same class should be returned) and fill the cache. The standard > smalltalk resolve method then would look like > > resolveGlobalByName: globalName cache: cache > Â | v | > Â v := Smalltalk at: v > Â cache bindTo: v > > where the cache is Smalltalk reflection object representing this > kind-of-inline cache. > When properly JITed, the cost of global access would the same as > before (except of the very first one) - ideally just one memory > fetch. > > Cheers, Jan > > >> >> -- >> View this message in context: >> http://forum.world.st/Pharo-and-Namespaces-tp4636635p4636978.html >> Sent from the Pharo Smalltalk mailing list archive at Nabble.com. >> >> > > > -- Best regards, Igor Stasenko.

June 27, 2012

Re: [Pharo-project] Pharo and Namespaces

by Sean P. DeNigris

Jan Vrany-3 wrote > > With proper caching at VM level, the performance overhead would be > negligible. > Good to know. Thanks! -- View this message in context: http://forum.world.st/Pharo-and-Namespaces-tp4636635p4637018.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

June 27, 2012

[Pharo-project] VM , modules, packages and plugins

by Igor Stasenko

Seeing another thread about "is XYZ plugin there or not" or "what may cause prim fail" i REALLY suggest that we should stop and think.. This plugin's usage logic is inherently flawed.. (or i would say outdated) What i would like to see one day is when i installing new code into image, it pops up a message: "Your VM missing an XYZ plugin for running this cool code, would you like to download and install it? Yes No " In case of Pharo, we should really start thinking about delivering quality grade solutions, not something which might work if you properly jump 2 times and whistle 7 times while faced North"... Look at what the practices which become common today in modern browsers, and OSes - they updating themselves without a notice and just asking you to restart it time to time. Why we cannot do the same? -- Best regards, Igor Stasenko.

June 27, 2012

Re: [Pharo-project] Do the VM's used on Jenkins include the SSL plugin ?

by Schwab,Wilhelm K

+20 :) ________________________________________ From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] on behalf of Igor Stasenko [siguctua(a)gmail.com] Sent: Wednesday, June 27, 2012 4:48 PM To: Pharo-project(a)lists.gforge.inria.fr Subject: Re: [Pharo-project] Do the VM's used on Jenkins include the SSL plugin ? We should really shift the paradigm of assuming that plugins is there towards having a nice error handling/presenting the reason why it fails, like in this case it should try and detect that plugin is not found/cannot be loaded and produce correct error message instead of "very informal" primitive failed message :)

June 27, 2012

Re: [Pharo-project] Do the VM's used on Jenkins include the SSL plugin ?

by Igor Stasenko

On 27 June 2012 23:53, Sven Van Caekenberghe <sven(a)beta9.be> wrote: > > On 27 Jun 2012, at 22:48, Igor Stasenko wrote: > >> We should really shift the paradigm of assuming that plugins is there towards >> having a nice error handling/presenting the reason why it fails, like >> in this case >> it should try and detect that plugin is not found/cannot be loaded and >> produce correct error message >> instead of "very informal" Â primitive failed message :) > > If you tell me the proper way to detect if a plugin is present, I will add a better exception. > This is where we in one boat, Sven :) I added a new primitive SmalltalkImage>>loadModule: aModuleName which is step towards it, but don't expect it to be working outside a pharo vms, because nobody else cares about that, and everyone else seem fine living in sandbox, where everything is safe, sun always shines, and all plugins are in place :) So, we really need to deal with that.. I grow tired seeing "primfailed" walkback mails over and over again in different dusty corners of our backyard (which VM is) and then educated guessing like what could possibly cause it.. Wake up: system should tell us what caused it, we should stop guessing and wasting our precious time on false alarms! So, in case of ssl plugin you can clearly tell that if that prim failed, you know that there's something wrong with plugin, i.e. it fails to initialize or not exists: so even putting more informal message "there seem to be problem with SSL plugin (missing? no SSL library installed on your system? ) will clarify a lot and prevent from wasting our time explaining why that prim might fail or which VM has SSL and which might not. -- Best regards, Igor Stasenko.

June 27, 2012