April 2012 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] What about making the configuration browser more visible?

by Guillermo Polito

On Fri, Apr 27, 2012 at 8:11 PM, Schwab,Wilhelm K <bschwab(a)anest.ufl.edu>wrote: > I know it's not a popular opinion, but overall, they don't work. It is > so bad that any effort on my part to fix one here or there would simply be > sticking a finger in a collapsing Hoover dam. "Yelling in general" is a > mis-characterization of my apparently being the only person willing to > characterize the emperor's new clothes. > > There are wide-spread problems. Either the configs need to be fixed, or > we need a common location for the latest incantation that is thought to > work with a given version of Pharo. > But then you have the same problem if people commit packages that do not work. :S Providing working versions and tagging them, right now is a people problem, not a tool problem. And the same happens with python, java, javascript, .net, ruby, the OS software... > > I don't know how else to put it. > > > > > > ------------------------------ > *From:* pharo-project-bounces(a)lists.gforge.inria.fr [ > pharo-project-bounces(a)lists.gforge.inria.fr] on behalf of Guillermo > Polito [guillermopolito(a)gmail.com] > *Sent:* Friday, April 27, 2012 1:37 PM > > *To:* Pharo-project(a)lists.gforge.inria.fr > *Subject:* Re: [Pharo-project] What about making the configuration > browser more visible? > > On Fri, Apr 27, 2012 at 7:25 PM, Schwab,Wilhelm K <bschwab(a)anest.ufl.edu > > wrote: > >> It's nice that there are examples that work, but the vast majority of >> configs are not so well organized. >> > > I'm not the mantainer of the majority of configs so I do not know. What I > explained before is how they are supposed to work and be managed. If the > person who mantains the config does not ensure you that, It's not the > problem of the configuration :). > > Now, if there are configs not working as expected, it would be good to: > - know them > - tell the mantainers > - try to fix one? > - not yelling in general because that does not work :S. > > From my side, this week I fixed the configurations of: > - Glamour > - OpenDBXDriver > - Glorp + GlorpDBX > - ScriptManager > > so they can load in latest 1.4. But I can't be everywhere yet :P. > > Also, 1.4 is has just been released, so I expect most users are moving > their stuff soon. > > Cheers, > Guille > > >> >> >> >> ------------------------------ >> *From:* pharo-project-bounces(a)lists.gforge.inria.fr [ >> pharo-project-bounces(a)lists.gforge.inria.fr] on behalf of Guillermo >> Polito [guillermopolito(a)gmail.com] >> *Sent:* Friday, April 27, 2012 12:26 PM >> >> *To:* Pharo-project(a)lists.gforge.inria.fr >> *Subject:* Re: [Pharo-project] What about making the configuration >> browser more visible? >> >> I meant: >> >> Example of 1) is you loading OmniBrowser or Nautilus. >> Example of 2) is your project using a specific version of XmlSupport or >> seaside. >> Example of 3) is the ImageBuilder of Mariano, which loads a lot of stuff >> to build a Development image. >> >> :P >> >> On Fri, Apr 27, 2012 at 6:26 PM, Guillermo Polito < >> guillermopolito(a)gmail.com> wrote: >> >>> Wat? Probably there was a misunderstood... >>> >>> 1) if you are an user of the project, stable should be enough and fine. >>> 2) if your project is coupled to the project, probably you are coupled >>> to an specific version. Thus, in your configuration you better put the >>> specific number :). >>> 3) if your project is not coupled to the project, just inteded to load >>> it, using stable should be enough and fine. >>> >>> Example of 1) is you loading OmniBrowser or Nautilus. >>> Example of 2) is your project using a specific version of XmlSupport or >>> seaside. >>> Example of 3) is the ImageBuilder of Mariano, which loads a lot of stuff >>> to build a Development image. >>> >>> Guille >>> >>> >>> On Fri, Apr 27, 2012 at 5:06 PM, Schwab,Wilhelm K <bschwab(a)anest.ufl.edu >>> > wrote: >>> >>>> Put another way, if it's that simple, why all the contrary instructions >>>> over time? >>>> >>>> >>>> ________________________________________ >>>> From: pharo-project-bounces(a)lists.gforge.inria.fr [ >>>> pharo-project-bounces(a)lists.gforge.inria.fr] on behalf of Camillo >>>> Bruni [camillobruni(a)gmail.com] >>>> Sent: Thursday, April 26, 2012 7:40 PM >>>> To: Pharo-project(a)lists.gforge.inria.fr >>>> Subject: Re: [Pharo-project] What about making the configuration >>>> browser more visible? >>>> >>>> On 2012-04-27, at 01:17, Schwab,Wilhelm K wrote: >>>> >>>> > Can they really download stuff? How much? Until the configurations >>>> are truly self-describing and "know" what to use for which version of >>>> Pharo[*], the Config Browser is really (sorry guys) a very clear >>>> illustration of what we have yet to do in the way of packaging. >>>> > >>>> > Bill >>>> > >>>> > [*] there needs to be one incantation that works to load everything, >>>> something like #loadStable. Then a config browser can work as advertised, >>>> and I fear, not until. Prove me wrong :) >>>> >>>> seems like you missed something (Metacello Configurations)? it's done >>>> like this in st-code: >>>> >>>> ConfigurationOfXYZ project load: #stable >>>> >>>> >>>> > ________________________________________ >>>> > From: pharo-project-bounces(a)lists.gforge.inria.fr [ >>>> pharo-project-bounces(a)lists.gforge.inria.fr] on behalf of StÃ©phane >>>> Ducasse [stephane.ducasse(a)inria.fr] >>>> > Sent: Thursday, April 26, 2012 6:17 PM >>>> > To: Pharo-project(a)lists.gforge.inria.fr >>>> > Subject: Re: [Pharo-project] What about making the configuration >>>> browser more visible? >>>> > >>>> > Ok for me. >>>> > Package Maps Loader >>>> > >>>> > Stef >>>> > >>>> >> What about naming it "Package Loader" or "Package center" or >>>> something like that? >>>> >> And putting it in the main menu instead of inside of Tools? >>>> >> >>>> >> I want people who open pharo for the first time to say "Hey, here I >>>> can download stuff!!!" >>>> >> >>>> >> Guille >>>> >>>> >>>> >>> >> >

April 27, 2012

Re: [Pharo-project] VNC for pharo 1.3 or 1.4

by Igor Stasenko

On 27 April 2012 20:05, Yanni Chiu <yanni(a)rogers.com> wrote: > On 26/04/12 10:45 PM, Paul DeBruicker wrote: >> >> You could also consider using 'xrpa' which is like screen but for X >> applications. Â See Bernat Romagosa description here: >> >> http://www.asmalltalkbytheseaside.com/#remotedevelopmentonpharowithoutvnc > > > In that article, the steps are: > > % xpra attach :5 > % DISPLAY=:5 ./pharo.sh > > which seems to imply that the 5-th DISPLAY port is occupied by the image. > > When I have several images running, using VNC, I can start/stop the VNC > display in each image (and specify the portno) using a Seaside interface. > > So, I only have to open one firewall port for the X Display port (I'm > probably doing something wrong here; maybe I should be using ssh), and I can > operate each image GUI as necessary, as long as I only operate on one image > at a time. > > Can a similar thing be done using xpra? > > is it wouldn't be easier to run desktop on X server with as many images you like, and connect x server instead using remote desktop connection? -- Best regards, Igor Stasenko.

April 27, 2012

Re: [Pharo-project] [Vm-dev] Re: [squeak-dev] CogVM binaries as per VMMaker.oscog-eem.157/r2550.

by Mariano Martinez Peck

On Fri, Apr 27, 2012 at 7:37 PM, Eliot Miranda <eliot.miranda(a)gmail.com>wrote: > > > > On Fri, Apr 27, 2012 at 12:57 AM, Mariano Martinez Peck < > marianopeck(a)gmail.com> wrote: > >> >> >> >> On Thu, Apr 19, 2012 at 6:06 PM, Eliot Miranda <eliot.miranda(a)gmail.com>wrote: >> >>> >>> >>> >>> On Thu, Apr 19, 2012 at 12:55 AM, Mariano Martinez Peck < >>> marianopeck(a)gmail.com> wrote: >>> >>>> >>>> >>>> On Thu, Apr 19, 2012 at 6:08 AM, Eliot Miranda <eliot.miranda(a)gmail.com >>>> > wrote: >>>> >>>>> http://www.mirandabanda.org/files/Cog/VM/VM.r2550/ >>>>> >>>>> CogVM binaries as per VMMaker.oscog-eem.157/r2550. >>>>> >>>>> Stack/CoInterpreter/Cogit: >>>>> Implement proper bounds checking for byte access to compiled >>>>> methods. Raise errors for accesses outside initialPC to size. >>>>> >>>>> CoInterpreter: >>>>> Provide a thorough flush primitive for CompiledMethods that discards all >>>>> machine code and makes sure that any contexts using the method have bytecode >>>>> pcs. Primitive #215 (same as 116 in the Stack VM). This is much slower than >>>>> 116 (flushCache) since it has to enumerate over all heap contexts. >>>>> >>>>> >>>> Excellent. Does it mean we should implement something like this: >>>> >>>> CompiledMethod >> flushCache >>>> "Tell the interpreter to remove all references to this method from >>>> its method lookup cache, if it has one. In addition, it provides a thorough >>>> flush primitive for CompiledMethods that discards all machine code and >>>> makes sure that any contexts using the method have bytecode >>>> pcs. >>>> This primitive must be called whenever a method is redefined or >>>> removed." >>>> <primitive: 215> >>>> self simpleFlushCache >>>> >>>> >>>> CompiledMethod >> simpleFlushCache >>>> "Tell the interpreter to remove all references to this method from >>>> its method lookup cache, if it has one. This primitive must be called >>>> whenever a method is redefined or removed." >>>> >>>> <primitive: 116>\ >>>> >>> >>> No. 215 is extremely expensive, because it scans the entire heap >>> looking for contexts using the method, and in the common case of redefining >>> a method it is unnecessary. It is only necessary if you modify a method >>> still in-use; read the comment of the attached method. >>> >>> Further, I would prefer to update the Interpreter to implement primitive >>> 215 using primitive 116, i.e. in the Interpreter's primitive table have both >>> >>> (116 primitiveFlushCacheByMethod) >>> ... >>> (215 primitiveFlushCacheByMethod) "primitiveVoidVMStateForMethod in the >>> CoInterpreter" >>> >>> This is what I've done in the StackInterpreter. In fact, we need to put >>> in time to bring the Interpreter's primitive set into agreement with Cog. >>> >>> >> >> Ok, I understand. Now, primitive 215 #primitiveVoidVMStateForMethod >> receives a CompiledMethod so we implement #voidCogVMState there. However, I >> see there is also primitive 214 #primitiveVoidVMState. Should we ALSO add >> something like >> >> voidCogVMState >> "Void all internal VM state in the stack and machine code zones >> <primitive: 214> >> ^self primitiveFailed >> >> >> But implemented in SmallttalkImage/VirtualMachine ?? >> > > Yes. Find attached. > >> >> Thanks. I did slice for Pharo. http://code.google.com/p/pharo/issues/detail?id=5728 > >> thanks! >> >> >>> >>> So I'm expecting we will have >>> >>> voidCogVMState >>> "Tell the VM to remove all references to any machine code form of the >>> method. >>> This primitive must be called whenever a method is in use and >>> modified. This is >>> more aggressive (and *much* more costly) than flushCache since it must >>> search >>> through all context objects, making sure that none have a (hidden) >>> machine code pc >>> in the receiver. Since modifying a method will likely change the >>> generated machine code, >>> modifying a method (rather than redefining it) requires this more >>> aggressive flush." >>> >>> <primitive: 215> >>> ^self primitiveFailed >>> >>> flushCache >>> "Tell the interpreter to remove all references to this method from its >>> method lookup cache, if it has one. This primitive must be called whenever >>> a method is defined or removed. >>> NOTE: Only one of two selective flush methods needs to be used. >>> Squeak 2.2 and earlier uses 119 (See Symbol flushCache). >>> Squeak 2.3 and later uses 116 (See CompiledMethod flushCache)." >>> >>> <primitive: 116> >>> >>> or >>> >>> voidCogVMState >>> "Tell the VM to remove all references to any machine code form of the >>> method. >>> This primitive must be called whenever a method is in use and >>> modified. This is >>> more aggressive (and *much* more costly) than flushCache since it must >>> search >>> through all context objects, making sure that none have a (hidden) >>> machine code pc >>> in the receiver. Since modifying a method will likely change the >>> generated machine code, >>> modifying a method (rather than redefining it) requires this more >>> aggressive flush." >>> >>> <primitive: 215> >>> ^self flushCache >>> >>> flushCache >>> "Tell the interpreter to remove all references to this method from its >>> method lookup cache, if it has one. This primitive must be called whenever >>> a method is defined or removed. >>> NOTE: Only one of two selective flush methods needs to be used. >>> Squeak 2.2 and earlier uses 119 (See Symbol flushCache). >>> Squeak 2.3 and later uses 116 (See CompiledMethod flushCache)." >>> >>> <primitive: 116> >>> >>> >>>> >>>> >>>> If you have a better name for #simpleFlushCache please let me know. >>>> if you agree, I will open an issue for this. >>>> >>>> Cheers >>>> >>>> >>>> >>>>> >>>>> Provide an xray primitive for CompiledMethod that answers if a method has >>>>> machine code, and if so if it's machine code is frameless, and/or refers >>>>> to a young object. No primitive number. Used to test the above. >>>>> >>>>> Make printOopShort: print Association keys. Useful for >>>>> longPrintOop:, and hence printReferencesTo: etc. >>>>> >>>>> Mac OS: add fflush to debug printing in sqMacUIEventsUniversal.c so output >>>>> appears promptly. >>>>> >>>>> Fix the annoying bogus error messages from the mprotect calls by getting the >>>>> length arg to mprotect right. >>>>> >>>>> Add version infor for the Cross/plugins tree. Add a -version switch to win32 >>>>> >>>>> -- >>>>> >>>>> best, >>>>> >>>>> Eliot >>>>> >>>>> >>>>> >>>>> >>>>> >>>> >>>> >>>> -- >>>> Mariano >>>> http://marianopeck.wordpress.com >>>> >>>> >>> >>> >>> -- >>> best, >>> Eliot >>> >>> >>> >> >> >> -- >> Mariano >> http://marianopeck.wordpress.com >> >> >> > > > -- > best, > Eliot > > > -- Mariano http://marianopeck.wordpress.com

April 27, 2012

Re: [Pharo-project] What about making the configuration browser more visible?

by Schwab,Wilhelm K

I know it's not a popular opinion, but overall, they don't work. It is so bad that any effort on my part to fix one here or there would simply be sticking a finger in a collapsing Hoover dam. "Yelling in general" is a mis-characterization of my apparently being the only person willing to characterize the emperor's new clothes. There are wide-spread problems. Either the configs need to be fixed, or we need a common location for the latest incantation that is thought to work with a given version of Pharo. I don't know how else to put it. ________________________________ From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] on behalf of Guillermo Polito [guillermopolito(a)gmail.com] Sent: Friday, April 27, 2012 1:37 PM To: Pharo-project(a)lists.gforge.inria.fr Subject: Re: [Pharo-project] What about making the configuration browser more visible? On Fri, Apr 27, 2012 at 7:25 PM, Schwab,Wilhelm K <bschwab(a)anest.ufl.edu<mailto:bschwab@anest.ufl.edu>> wrote: It's nice that there are examples that work, but the vast majority of configs are not so well organized. I'm not the mantainer of the majority of configs so I do not know. What I explained before is how they are supposed to work and be managed. If the person who mantains the config does not ensure you that, It's not the problem of the configuration :). Now, if there are configs not working as expected, it would be good to: - know them - tell the mantainers - try to fix one? - not yelling in general because that does not work :S. >From my side, this week I fixed the configurations of: - Glamour - OpenDBXDriver - Glorp + GlorpDBX - ScriptManager so they can load in latest 1.4. But I can't be everywhere yet :P. Also, 1.4 is has just been released, so I expect most users are moving their stuff soon. Cheers, Guille ________________________________ From: pharo-project-bounces(a)lists.gforge.inria.fr<mailto:pharo-project-bounces@lists.gforge.inria.fr> [pharo-project-bounces(a)lists.gforge.inria.fr<mailto:pharo-project-bounces@lists.gforge.inria.fr>] on behalf of Guillermo Polito [guillermopolito(a)gmail.com<mailto:guillermopolito@gmail.com>] Sent: Friday, April 27, 2012 12:26 PM To: Pharo-project(a)lists.gforge.inria.fr<mailto:Pharo-project@lists.gforge.inria.fr> Subject: Re: [Pharo-project] What about making the configuration browser more visible? I meant: Example of 1) is you loading OmniBrowser or Nautilus. Example of 2) is your project using a specific version of XmlSupport or seaside. Example of 3) is the ImageBuilder of Mariano, which loads a lot of stuff to build a Development image. :P On Fri, Apr 27, 2012 at 6:26 PM, Guillermo Polito <guillermopolito(a)gmail.com<mailto:guillermopolito@gmail.com>> wrote: Wat? Probably there was a misunderstood... 1) if you are an user of the project, stable should be enough and fine. 2) if your project is coupled to the project, probably you are coupled to an specific version. Thus, in your configuration you better put the specific number :). 3) if your project is not coupled to the project, just inteded to load it, using stable should be enough and fine. Example of 1) is you loading OmniBrowser or Nautilus. Example of 2) is your project using a specific version of XmlSupport or seaside. Example of 3) is the ImageBuilder of Mariano, which loads a lot of stuff to build a Development image. Guille On Fri, Apr 27, 2012 at 5:06 PM, Schwab,Wilhelm K <bschwab(a)anest.ufl.edu<mailto:bschwab@anest.ufl.edu>> wrote: Put another way, if it's that simple, why all the contrary instructions over time? ________________________________________ From: pharo-project-bounces(a)lists.gforge.inria.fr<mailto:pharo-project-bounces@lists.gforge.inria.fr> [pharo-project-bounces(a)lists.gforge.inria.fr<mailto:pharo-project-bounces@lists.gforge.inria.fr>] on behalf of Camillo Bruni [camillobruni(a)gmail.com<mailto:camillobruni@gmail.com>] Sent: Thursday, April 26, 2012 7:40 PM To: Pharo-project(a)lists.gforge.inria.fr<mailto:Pharo-project@lists.gforge.inria.fr> Subject: Re: [Pharo-project] What about making the configuration browser more visible? On 2012-04-27, at 01:17, Schwab,Wilhelm K wrote: > Can they really download stuff? How much? Until the configurations are truly self-describing and "know" what to use for which version of Pharo[*], the Config Browser is really (sorry guys) a very clear illustration of what we have yet to do in the way of packaging. > > Bill > > [*] there needs to be one incantation that works to load everything, something like #loadStable. Then a config browser can work as advertised, and I fear, not until. Prove me wrong :) seems like you missed something (Metacello Configurations)? it's done like this in st-code: ConfigurationOfXYZ project load: #stable > ________________________________________ > From: pharo-project-bounces(a)lists.gforge.inria.fr<mailto:pharo-project-bounces@lists.gforge.inria.fr> [pharo-project-bounces(a)lists.gforge.inria.fr<mailto:pharo-project-bounces@lists.gforge.inria.fr>] on behalf of StÃ©phane Ducasse [stephane.ducasse(a)inria.fr<mailto:stephane.ducasse@inria.fr>] > Sent: Thursday, April 26, 2012 6:17 PM > To: Pharo-project(a)lists.gforge.inria.fr<mailto:Pharo-project@lists.gforge.inria.fr> > Subject: Re: [Pharo-project] What about making the configuration browser more visible? > > Ok for me. > Package Maps Loader > > Stef > >> What about naming it "Package Loader" or "Package center" or something like that? >> And putting it in the main menu instead of inside of Tools? >> >> I want people who open pharo for the first time to say "Hey, here I can download stuff!!!" >> >> Guille

April 27, 2012

Re: [Pharo-project] VNC for pharo 1.3 or 1.4

by Yanni Chiu

On 26/04/12 10:45 PM, Paul DeBruicker wrote: > You could also consider using 'xrpa' which is like screen but for X > applications. See Bernat Romagosa description here: > > http://www.asmalltalkbytheseaside.com/#remotedevelopmentonpharowithoutvnc In that article, the steps are: % xpra attach :5 % DISPLAY=:5 ./pharo.sh which seems to imply that the 5-th DISPLAY port is occupied by the image. When I have several images running, using VNC, I can start/stop the VNC display in each image (and specify the portno) using a Seaside interface. So, I only have to open one firewall port for the X Display port (I'm probably doing something wrong here; maybe I should be using ssh), and I can operate each image GUI as necessary, as long as I only operate on one image at a time. Can a similar thing be done using xpra?

April 27, 2012

Re: [Pharo-project] http://book.pharo-project.org/ down

by Guillermo Polito

:3 Thanks Dale! On Fri, Apr 27, 2012 at 7:59 PM, Dale Henrichs <dhenrich(a)vmware.com> wrote: > The vm hung for some reason ... restarted the vm and it's back online ... > > Dale > > ----- Original Message ----- > | From: "Guillermo Polito" <guillermopolito(a)gmail.com> > | To: "Pharo Development" <Pharo-project(a)lists.gforge.inria.fr> > | Sent: Friday, April 27, 2012 10:39:36 AM > | Subject: [Pharo-project] http://book.pharo-project.org/ down > | > | :( > | > >

April 27, 2012

Re: [Pharo-project] SSL plugin for linux

by Igor Stasenko

On 27 April 2012 19:37, Schwab,Wilhelm K <bschwab(a)anest.ufl.edu> wrote: > Is there an ssl socket/stream to go with it? > > Zodiac.. i don't know much details since i never used it. Ask Sven bout it :) > > ________________________________________ > 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: Friday, April 27, 2012 1:29 PM > To: Squeak Virtual Machine Development Discussion; Pharo Development > Subject: [Pharo-project] SSL plugin for linux > > hi, i built ssl plugin > > i didn't tested but at least it find it and loads and i were able to > run 1st primitive: > > primitiveSSLCreate > Â Â Â "Primitive. Creates and returns a new SSL handle in the VM plugin" > > Â Â Â <primitive: 'primitiveCreate' module: 'SqueakSSL'> > > Â Â Â ^ self primitiveFailed > > > i updated the configuration & added missing source files in this commit: > > https://gitorious.org/cogvm/blessed/commit/59ef1cb1c70a93ed3c974b5d6beea0e4… > > to build SSL plugin you must have ssl, and ssl-dev libs installed: > > > sudo apt-get install openssl > sudo apt-get install libssl-dev > > > You can download prebuilt plugin from here: > > http://code.google.com/p/cog/downloads/detail?name=libSqueakSSL.so.gz&can=2… > > (it is with debug info, since i used debug config to build it) > > To build it, you shoud use Â >= CMakeVMMaker-IgorStasenko.157 > and > > CogUnixConfig new > addExternalPlugins: #( ... yours ... Â SqueakSSLPlugin ) > generateSources; generate. > > > please try plugin, if it works, so we can include it in standard build > and be built automatically on jenkins server. > > -- > Best regards, > Igor Stasenko. > > -- Best regards, Igor Stasenko.

April 27, 2012

Re: [Pharo-project] http://book.pharo-project.org/ down

by Dale Henrichs

The vm hung for some reason ... restarted the vm and it's back online ... Dale ----- Original Message ----- | From: "Guillermo Polito" <guillermopolito(a)gmail.com> | To: "Pharo Development" <Pharo-project(a)lists.gforge.inria.fr> | Sent: Friday, April 27, 2012 10:39:36 AM | Subject: [Pharo-project] http://book.pharo-project.org/ down | | :( |

April 27, 2012

[Pharo-project] http://book.pharo-project.org/ down

by Guillermo Polito

:(

April 27, 2012

Re: [Pharo-project] SSL plugin for linux

by Schwab,Wilhelm K

Is there an ssl socket/stream to go with it? ________________________________________ 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: Friday, April 27, 2012 1:29 PM To: Squeak Virtual Machine Development Discussion; Pharo Development Subject: [Pharo-project] SSL plugin for linux hi, i built ssl plugin i didn't tested but at least it find it and loads and i were able to run 1st primitive: primitiveSSLCreate "Primitive. Creates and returns a new SSL handle in the VM plugin" <primitive: 'primitiveCreate' module: 'SqueakSSL'> ^ self primitiveFailed i updated the configuration & added missing source files in this commit: https://gitorious.org/cogvm/blessed/commit/59ef1cb1c70a93ed3c974b5d6beea0e4… to build SSL plugin you must have ssl, and ssl-dev libs installed: sudo apt-get install openssl sudo apt-get install libssl-dev You can download prebuilt plugin from here: http://code.google.com/p/cog/downloads/detail?name=libSqueakSSL.so.gz&can=2… (it is with debug info, since i used debug config to build it) To build it, you shoud use >= CMakeVMMaker-IgorStasenko.157 and CogUnixConfig new addExternalPlugins: #( ... yours ... SqueakSSLPlugin ) generateSources; generate. please try plugin, if it works, so we can include it in standard build and be built automatically on jenkins server. -- Best regards, Igor Stasenko.

April 27, 2012