- Pharo-dev - lists.pharo.org

Re: [Pharo-project] Decompiler problem (leading to infinite loop of opening debuggers)
by Marcus Denker May 18, 2011

May 18, 2011

On May 18, 2011, at 1:26 PM, Toon Verwaest wrote: > I haven't figured out the exact decompiler bug yet, but just so you can easily fix your problem: > I tested on 1.3, and it's fixed there... we synced in 1.3 with some fixes from the old compiler. We could backport the compiler fixes to 1.2... > just move the temp in the whileFalse: [ |newReqd| to the toplevel of the method (if this is semantically equivalent; but it looks like). > Then it can actually decompile it ;) > > cheers, > Toon > > On 05/18/2011 12:16 PM, Johan Brichau wrote: >> (MetacelloMCVersionSpec compiledMethodAt: #resolveToLoadableSpecs:map:) decompileWithTemps > > -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD.

4 3

[Pharo-project] Basic tricks for improving a serializer?
by Mariano Martinez Peck May 18, 2011

May 18, 2011

Hi guys. Together with Martin we are developing a fast object graph serializer called Fuel. The idea is to use a pickle format similar to VW Parcels. Right now we are able to correctly serialize (almost) all kind of objects (from different classes and so on). The algorithm is working quite well and we are already quite fast. We also know how to encode more or less efficient some of the "primitive" classes like Floats, SmallIntegers, ByteString, ByteArray, etc, etc. What we really don't know anything about streams. For example, until now, we were using just a MultiByteFileStream and doing all the time things like #next: #nextPutAll: #nextWordPut: etc... Now Igor told us for example, to use a buffer like this: | bufferStream | bufferStream := ByteArray new writeStream. (FLSerializer on: bufferStream) serialize: anArrayToSerialize. aFileStream nextPutAll: bufferStream contents. and that it at least 2 times faster than we were doing.... I guess it is because it goes to the disk only once. But MultiByteFileStream uses a buffer, doesn't it ? For reading (deserialization) we are not doing nothing special. We just open the file stream and we read with #next #nextString ... etc. Another thing is which kind of file stream should we use. MultiByteFileStream ? StandardFileStream ? So...before spending time in some optimizations, are there "known" things that we should check? Thanks in advance, -- Mariano http://marianopeck.wordpress.com

7 19

Re: [Pharo-project] [Esug-list] [ANN] SmallHarbour project
by Dale Henrichs May 18, 2011

May 18, 2011

On 05/17/2011 12:37 PM, Davorin Rusevljan wrote: > On Tue, May 17, 2011 at 9:19 PM, laurent laffont > <laurent.laffont(a)gmail.com> wrote: >> Actually we have several visions (nothing is final here, ideas welcome) > .. > > Having Amazon ec2 image is also a very good idea, and some > Smalltalkers have already made first important steps like: > > http://www.nickager.com/blog/Create-a-free-Gemstone-server-in-the-cloud-in-… > > You probably already have enough on your plate, but I mentioned > CloudFoundry for following reasons: > - it has a promise that one would be able to deploy SmallHarbour to > different cloud providers > - CloudFoundry currently provides support for Java, Ruby and > Javascript, adding Smalltalk would be nice for visibility, and could > be used for other Smalltalk services not only SmallHarbour. > > As I said you probably have enough to do in the first place, but if > you just happen to have some student lurking that has some ruby > knowledge to hack the interface for Smalltalk to Cloudfoundry it would > be very nice to have :) > > As for your other goals - great! > > Davorin Rusevljan > http://www.cloud208.com/ > > _______________________________________________ > Esug-list mailing list > Esug-list(a)lists.esug.org > http://lists.esug.org/mailman/listinfo/esug-list_lists.esug.org Laurent/Davorin, We are in the process of adding support for deploying GLASS applications into the Cloud Foundry, but I wouldn't mind helping folks who are interested in adding support for other Smalltalks into the Cloud Foundry ... The Cloud Foundry is written largely in ruby, so you'll need to be wearing your ruby dancing shoes:) Dale

5 7

[Pharo-project] RDF Framework and Pharo
by Laszlo Zsolt Kiss May 18, 2011

May 18, 2011

Hello.How can I usingÂ Rikaiko RDF framework with Pharo 1.2 or 1.3?Anybody working with this stuff?Best regardsLaszlo Zsolt Kiss

4 5

[Pharo-project] Zodiac - 2nd delivery - A new (binary) secure socket stream + Zn clients doing HTTPS
by Sven Van Caekenberghe May 18, 2011

May 18, 2011

Hi, Here is the second delivery of Zodiac: A new (binary) secure socket stream and the ability of the Zinc HTTP Components clients to do HTTPS. Warning: this is of course not yet code for general consumption, use the source and the comments. This is a proof of concept. ZdcSecureSocketStream, a subclass of ZdcOptimizedSocketStream was added. This implementation works together with both a Socket and with a ZdcAbstractSSLSession object, of which there is currently one implementation, ZdcPluginSSLSession. Loading this code is safe, to make it work though, you need to add a plugin to your VM. Please go to http://code.google.com/p/squeakssl/ and download the apropriate plugin for your platform and put it next to the other plugins. Disclaimer: I only tested on Mac OS X, but the plugin should work on the other platforms. The Smalltalk code works on Pharo 1.2 and 1.3 as well as on Squeak 4.2 with any modifications. There is currently just one simple test in Zodiac itself. What is nicer though, is the fact the Zinc HTTP Components clients can now do HTTPS ! Load the latest version of Zinc-Zodiac from the ZincHTTPComponents repository and enable the socket stream factory: ZnNetworkingUtils default: ZnZodiacNetworkingUtils new. Tada: you should now be able to do any of the following ZnClient get: 'https://encrypted.google.com/search?q=Smalltalk' ZnHttpClient new get: 'https://www.gmail.com' ZnHttpClient new get: 'https://secure.wikimedia.org/' ZnHttpClient new get: 'http://gforge.inria.fr/frs/?group_id=1299' ZnHttpClient new get: 'https://www.paypal.com' ZnClient get: 'https://aws.amazon.com/' These are all part of ZnHTTPSTests. (The difference between ZnClient and ZnHttpClient is that the latter has more options, follows redirects, deals with cookies, ..). When you have Zinc-Patch-HTTPSocket loaded (which is the case in Pharo 1.3 Core and derivatives) the legacy interface will work as well: HTTPSocket httpGet: 'https://encrypted.google.com/search?q=Smalltalk' Please note that certificate management or checking the server's certificate or hostname is not yet supported. There will probably be many use cases that give errors. If you have examples that I can easily reproduce, please let me know. There is still a good way to go, but I think this is an important step. Sven

1 0

[Pharo-project] ConfigurationOfOmnibrowser
by Alexandre Bergel May 18, 2011

May 18, 2011

Hi! Apparently, baseline13: does not specific where to grab OB from. I added a line "spec repository: 'http://source.lukas-renggli.ch/omnibrowser'." and it works for me. But I am wondering why we did not bump into this problem before? Cheers, Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

2 1

Re: [Pharo-project] out of memory - cog on windows
by Tudor Girba May 18, 2011

May 18, 2011

> Hi again, > > I did not say what the problem was :). The problem was that when opening the image on Windows, he got a Space is low message and the image was not usable (see attachment). On Mac it worked just fine. > > Cheers, > Doru > > > > > > On 21 Apr 2011, at 12:52, Tudor Girba wrote: > >> Hi, >> >> I received a question from someone running a 200MB image on Windows using Cog 2361. >> >> If I open the image on Mac, it works just fine. Unfortunately, I do not have a Windows machine around, and I cannot test but I believe it should be solvable by increasing the allocated memory. >> >> On Mac, I would run it with: ./Croquet -memory 1500m >> >> Can anyone help me with the right incantation for Windows? >> >> Cheers, >> Doru >> >> >> -- >> www.tudorgirba.com >> >> "What we can governs what we wish." >> >> >> >> <Space is low.png> > > -- > www.tudorgirba.com > > "Yesterday is a fact. > Tomorrow is a possibility. > Today is a challenge." > > >

6 26

[Pharo-project] [Hudson] Filesystem testrunner
by Marcus Denker May 18, 2011

May 18, 2011

https://pharo-ic.lille.inria.fr/hudson/job/Filesystem/ 1.3, rebuild after every core update. -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD.

1 0

Re: [Pharo-project] Decompiler problem (leading to infinite loop of opening debuggers)
by Marcus Denker May 18, 2011

May 18, 2011

On May 18, 2011, at 1:32 PM, Toon Verwaest wrote: > On 05/18/2011 01:30 PM, Marcus Denker wrote: >> On May 18, 2011, at 1:26 PM, Toon Verwaest wrote: >> >>> I haven't figured out the exact decompiler bug yet, but just so you can easily fix your problem: >>> >> I tested on 1.3, and it's fixed there... we synced in 1.3 with some fixes from the old compiler. >> >> We could backport the compiler fixes to 1.2... > Oh ok, then I don't even look further. But that decompiler is a mess ... moving to OPAL would be a great improvement I'd say ... :-) -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD.

1 0

[Pharo-project] Decompiler problem (leading to infinite loop of opening debuggers)
by Johan Brichau May 18, 2011

May 18, 2011

Hi, In Pharo1.2.x, I get an infinite recursion of a debugger windows opening when I load a metacello config that has a problem in it. The relevant problem can be reconstructed (without the infinite loop :-) by evaluation the following: (MetacelloMCVersionSpec compiledMethodAt: #resolveToLoadableSpecs:map:) decompileWithTemps I'm absolutely no compiler guy, so I'm totally unaware of what is happening. But it's serious because I cannot debug the actual problem of the metacello config because of this. It was tried with Pharo1.2.1 and Pharo1.2.2-12353 and latest Cog VM (27 April 2011). I entered issue 4241 in the bug tracker for this. Johan

2 1