- Pharo-dev - lists.pharo.org

[Pharo-project] Is there a http server that understands PUT?

by Norbert Hartl

While trying to consume some PUT urls with Seaside-REST I noticed that the transmitted content is missing. I tried Comanche as well as swazoo. At this moment I'm not sure if I did something wrong but I seems that only GET and POST are treated. Does anyone has some experience on this? thanks, Norbert

Jan. 17, 2011

Re: [Pharo-project] [Pharo-users] Where do I find KeyedSet?

by HernÃ¡n Morales Durand

Hi, and thanks for the clarification Levente, This points me to a question, since it seems KeyedSet was removed because at that time no users were found. Is that the criteria (i.e. no users) for removing a class from the Core image? Assuming you have NO resources for checking use of classes by the users, and core developers have NO care/time/energy for annotating their changes (or there is no tool to do it or nobody uses it), I have this idea: You continue deleting classes as if nothing happens, BUT let users to vote for a request an addition or NOT removal. Then you win on two aspects: -First you get a free log of what has been removed -When votes reach a consensus value, that you may seriously consider including whatever is in question. How about tagging issues like [RFI] (Request for Inclusion) ? And every comment counts like a vote. Opinions? HernÃ¡n 2011/1/15 Levente Uzonyi <leves(a)elte.hu>: > On Sat, 15 Jan 2011, HernÃ¡n Morales Durand wrote: > >> Hi Stef >> >> 2011/1/15 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>: >>> >>> On Jan 14, 2011, at 6:24 PM, HernÃ¡n Morales Durand wrote: >>> >>>> Try PluggableSet > > Note that KeyedSet has nothing to do with PluggableSet. PluggableSet is a > set where you can specify the hash and equality of two objects with blocks. > This gives you great flexibility without creating a subclass of Set. > KeyedSet is like a dictionary, but the keys of the objects are not stored in > the data structure, because the objects know it themselves. This means that > the data structure will have a smaller memory footprint. > > > Levente > >>>> >>>> >>>> http://www.mail-archive.com/pharo-project@lists.gforge.inria.fr/msg22890.ht… >>>> >>>> Is there a way for you guys to deprecate deleted classes or mantain a >>>> record of deleted behaviors? (IIRC VW did this from 2.x versions) >>> >>> We try but we do not have the engineers of VW. >>> Now find somebody that pay us just 3 engineers full time for two years >>> and you will not >>> recognized pharo and its process. >> >> I know we are very few, but what about this idea, instead of just >> deleting a class we may adopt these simple rules: >> >> 1 - If deleting a class add the deleted class name somewhere (in a >> method?) >> 2 - If renaming a class, make the class to know its previous names >> like #previousNames >> (Norberto Manzanos implemented this for his own package management and >> I think is a great idea) >> >> doesn't require tools, just some consensus and maybe a modified >> #deleteClass to enforce this "policy" >> >> it sounds feasible for you? what do you think? >> >> HernÃ¡n >> >

Jan. 17, 2011

Re: [Pharo-project] pharogenesis

by Max Leske

Well, if we're dreaming anyway: My dream is to interact with a remote git repo. Because at the moment, to use Pharogenesis, one has to clone the repository and keep in mind to include all the tags and branches. It would be cool to have the network protocols integrated into GitFS. But that's a whole project on its own. Thanks for the interest anyway! Feels good to do something that might actually be used or lead to a real change. Max On 17.01.2011, at 17:35, Norbert Hartl wrote: > > On 17.01.2011, at 16:41, Max Leske wrote: > >> I'm not quite sure I can follow you. Do you want to import the full repository into the image? Or would you want SystemDictionary to hold simply the version of every method that was active *before* the current version? >> >> The first case is a no go I think. The packed repository is 101 MB big and there are still 11000 object files in addition to the pack and index file. >> The second case would definitely speed up the look up process but on the other hand it doesn't solve the problem that you need another mechanism in the background (like a DB) to hold further versions. >> >> Was that even close to what you wanted? >> > I thought about the first one. I didn't think about resource restrictions at first. Just that the best case IMHO would be to have everything at hand extending only the MOP/query calls by a version dimension. It would then be possible to instantiate old objects and play with them. > But then I was just day dreaming and it has less to do with what you are doing :) > > Norbert >> >> On 17.01.2011, at 10:25, Norbert Hartl wrote: >> >>> >>> On 16.01.2011, at 21:46, StÃ©phane Ducasse wrote: >>> >>>> I would love to have all these versions in a database and that we can query them :) >>>> >>> I thought the same. But then I didn't think about database. Wouldn't that be possible if the environment SystemDictionary is in full use? Would it be possible to import a version into a SystemDictionary that reflects one version and that is accesible through the class via class history?. Or is this a rather stupid idea? >>> >>> Norbert >>> >>>> On Jan 16, 2011, at 12:26 PM, Max Leske wrote: >>>> >>>>> Hi Geert >>>>> >>>>> Pharogenesis is my bachelors thesis and I'm still not finished writing it. I'll let you know when I'm finished. >>>>> >>>>> In short: I'm hosting a git repository on github that contains the information from the changes and sources files starting at Squeak version 1 up to Squeak 4.0 and Pharo 1.0. The idea is to have a single point of entry to that information so that one could for instance find out about every change to a method back to its creation. >>>>> >>>>> To accomplish this I built an implementation of git called GitFS that uses Filesystem (it's based on GitForSqueak by Tony Garnock-Jones). You can find everything on Squeaksource: http://squeaksource.com/@gUSXOmZmeac-jt63/3ejuPFSA >>>>> In that repo is also the code I use to generate the repository. >>>>> >>>>> Feel free to use the code and the repo but keep in mind that I'm still working on it. >>>>> >>>>> Max >>>>> >>>>> >>>>> >>>>> On 16.01.2011, at 11:38, Geert Claes wrote: >>>>> >>>>>> >>>>>> Hi Max, Can you tell us a little bit about pharogenesis? >>>>>> -- >>>>>> View this message in context: http://forum.world.st/pharogenesis-tp3219872p3219893.html >>>>>> Sent from the Pharo Smalltalk mailing list archive at Nabble.com. >>>>>> >>>>> >>>>> >>>> >>>> >>> >>> >> >> > >

Jan. 17, 2011

Re: [Pharo-project] pharogenesis

by Norbert Hartl

On 17.01.2011, at 16:41, Max Leske wrote: > I'm not quite sure I can follow you. Do you want to import the full repository into the image? Or would you want SystemDictionary to hold simply the version of every method that was active *before* the current version? > > The first case is a no go I think. The packed repository is 101 MB big and there are still 11000 object files in addition to the pack and index file. > The second case would definitely speed up the look up process but on the other hand it doesn't solve the problem that you need another mechanism in the background (like a DB) to hold further versions. > > Was that even close to what you wanted? > I thought about the first one. I didn't think about resource restrictions at first. Just that the best case IMHO would be to have everything at hand extending only the MOP/query calls by a version dimension. It would then be possible to instantiate old objects and play with them. But then I was just day dreaming and it has less to do with what you are doing :) Norbert > > On 17.01.2011, at 10:25, Norbert Hartl wrote: > >> >> On 16.01.2011, at 21:46, StÃ©phane Ducasse wrote: >> >>> I would love to have all these versions in a database and that we can query them :) >>> >> I thought the same. But then I didn't think about database. Wouldn't that be possible if the environment SystemDictionary is in full use? Would it be possible to import a version into a SystemDictionary that reflects one version and that is accesible through the class via class history?. Or is this a rather stupid idea? >> >> Norbert >> >>> On Jan 16, 2011, at 12:26 PM, Max Leske wrote: >>> >>>> Hi Geert >>>> >>>> Pharogenesis is my bachelors thesis and I'm still not finished writing it. I'll let you know when I'm finished. >>>> >>>> In short: I'm hosting a git repository on github that contains the information from the changes and sources files starting at Squeak version 1 up to Squeak 4.0 and Pharo 1.0. The idea is to have a single point of entry to that information so that one could for instance find out about every change to a method back to its creation. >>>> >>>> To accomplish this I built an implementation of git called GitFS that uses Filesystem (it's based on GitForSqueak by Tony Garnock-Jones). You can find everything on Squeaksource: http://squeaksource.com/@gUSXOmZmeac-jt63/3ejuPFSA >>>> In that repo is also the code I use to generate the repository. >>>> >>>> Feel free to use the code and the repo but keep in mind that I'm still working on it. >>>> >>>> Max >>>> >>>> >>>> >>>> On 16.01.2011, at 11:38, Geert Claes wrote: >>>> >>>>> >>>>> Hi Max, Can you tell us a little bit about pharogenesis? >>>>> -- >>>>> View this message in context: http://forum.world.st/pharogenesis-tp3219872p3219893.html >>>>> Sent from the Pharo Smalltalk mailing list archive at Nabble.com. >>>>> >>>> >>>> >>> >>> >> >> > >

Jan. 17, 2011

Re: [Pharo-project] 502 Bad Gateway

by HwaJong Oh

it worked! thanks! 2011. 1. 17., ì ë 10:00, Guillermo Polito [via Smalltalk] ìì±: > It seems squeaksource went down. It looks ok now(http://www.squeaksource.com), can you try again? > > Cheers, > Guille > > On Sun, Jan 16, 2011 at 11:28 PM, HwaJong Oh <[hidden email]> wrote: > > I have this error while copying mcz file from my directory repo to > pharoInbox. > It was working well a minute ago. > > 'HTTP/1.1 502 Bad Gateway > Date: Mon, 17 Jan 2011 02:20:01 GMT > Server: Apache/1.3.41 (Darwin) mod_jk/1.2.6 mod_ssl/2.8.31 OpenSSL/0.9.7l > PHP/4.4.9 > Last-Modified: Fri, 22 Dec 2006 12:14:34 GMT > ETag: "ee86f-a68-458bcc2a" > Accept-Ranges: bytes > Content-Length: 2664 > Connection: close > Content-Type: text/html<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 > Strict//EN" > "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd"> > > <html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en"> > <head> > <link rel="stylesheet" type="text/css" href="/squeaksource/style.css" /> > <meta name="verify-v1" > content="aYJ5chz2x0fRQuxMBS4pW+Ikb7hgtaBsysf18Fbt3q8=" /> > <title>SqueakSource</title> > </head> > > <body> > <div id="container"> > <div id="top"> > </div> > > <div id="sstoolbar"> > http://www.squeaksource.com/ Home > http://www.squeaksource.com/ Projects > http://www.squeaksource.com/ Tags > http://www.squeaksource.com/ Members > http://www.squeaksource.com/ Groups > http://www.squeaksource.com/ Help > </div> > > <div id="page"> > <div id="navigation"> > <div class="title"> > Actions > </div> > <div class="item"> > http://www.squeaksource.com/ Refresh > </div> > </div> > > <div id="contents"> > <h1>SqueakSource Down</h1> > > <p style="font-weight: bold; margin-left: 20px; margin-right: 220px; > line-height: 1.5em"> > SqueakSource is currently down. We are sorry for the inconvenience and > working on the problem. In the meantime you can still commit to a > directory repository on your disk and later copy the versions to > SqueakSource.</p> > > <p>This service is brought to you for free: it is backed up daily. > Still, please make sure that you have your own proper backups and > note > that we cannot give any accessibility guarantees. However, if you > wish > you can set up your own SqueakSource server. It is self-hosted and > can > be downloaded from SqueakMap.</p> > > <p>Please report any problems or suggestions to the Squeak > http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/squeak-dev > Mailing-List . Enjoy!</p> > > <p>We gratefully acknowledge the support of the > http://www.iam.unibe.ch/%7Escg/ Software Composition Group and > the http://www.unibe.ch/ University of Bern for hosting > this service.</p> > </div> > > <div id="bottom"> > <table width="100%" border="0" cellspacing="0" cellpadding="0"> > <tr> > <td align="left"> > http://validator.w3.org/check/referer XHTML > | http://jigsaw.w3.org/css-validator/check/referer CSS > </td> > <td align="right">It''s a sad day</td> > </tr> > </table> > </div> > </div> > </body> > </html> > ' > -- > View this message in context: http://forum.world.st/502-Bad-Gateway-tp3220636p3220636.html > Sent from the Pharo Smalltalk mailing list archive at Nabble.com. > > > > > View message @ http://forum.world.st/502-Bad-Gateway-tp3220636p3221177.html > To unsubscribe from 502 Bad Gateway, click here. -- View this message in context: http://forum.world.st/502-Bad-Gateway-tp3220636p3221224.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

Jan. 17, 2011

Re: [Pharo-project] pharogenesis

by Max Leske

I'm not quite sure I can follow you. Do you want to import the full repository into the image? Or would you want SystemDictionary to hold simply the version of every method that was active *before* the current version? The first case is a no go I think. The packed repository is 101 MB big and there are still 11000 object files in addition to the pack and index file. The second case would definitely speed up the look up process but on the other hand it doesn't solve the problem that you need another mechanism in the background (like a DB) to hold further versions. Was that even close to what you wanted? Max On 17.01.2011, at 10:25, Norbert Hartl wrote: > > On 16.01.2011, at 21:46, StÃ©phane Ducasse wrote: > >> I would love to have all these versions in a database and that we can query them :) >> > I thought the same. But then I didn't think about database. Wouldn't that be possible if the environment SystemDictionary is in full use? Would it be possible to import a version into a SystemDictionary that reflects one version and that is accesible through the class via class history?. Or is this a rather stupid idea? > > Norbert > >> On Jan 16, 2011, at 12:26 PM, Max Leske wrote: >> >>> Hi Geert >>> >>> Pharogenesis is my bachelors thesis and I'm still not finished writing it. I'll let you know when I'm finished. >>> >>> In short: I'm hosting a git repository on github that contains the information from the changes and sources files starting at Squeak version 1 up to Squeak 4.0 and Pharo 1.0. The idea is to have a single point of entry to that information so that one could for instance find out about every change to a method back to its creation. >>> >>> To accomplish this I built an implementation of git called GitFS that uses Filesystem (it's based on GitForSqueak by Tony Garnock-Jones). You can find everything on Squeaksource: http://squeaksource.com/@gUSXOmZmeac-jt63/3ejuPFSA >>> In that repo is also the code I use to generate the repository. >>> >>> Feel free to use the code and the repo but keep in mind that I'm still working on it. >>> >>> Max >>> >>> >>> >>> On 16.01.2011, at 11:38, Geert Claes wrote: >>> >>>> >>>> Hi Max, Can you tell us a little bit about pharogenesis? >>>> -- >>>> View this message in context: http://forum.world.st/pharogenesis-tp3219872p3219893.html >>>> Sent from the Pharo Smalltalk mailing list archive at Nabble.com. >>>> >>> >>> >> >> > >

Jan. 17, 2011

Re: [Pharo-project] Unsubscribing for Announcements

by Schwab,Wilhelm K

Two comments: (1) there needs to be a way to unregister interest; (2) the registrations need to be weak so that (1) is largely optional. If Dolphin has a weakness, it is that failure of an MVP triad to open can leave the system in a confused state. Morphic appears to be a little more robust about that, though in fairness, I do not push Pharo's GUI nearly as hard as I have Dolphin's. If in doubt, some type of #ifCurtailed: or similar protection around the assembly of a complex morph might be a good idea. ________________________________________ From: pharo-project-bounces(a)lists.gforge.inria.fr [pharo-project-bounces(a)lists.gforge.inria.fr] On Behalf Of Sean P. DeNigris [sean(a)clipperadams.com] Sent: Monday, January 17, 2011 1:18 AM To: pharo-project(a)lists.gforge.inria.fr Subject: [Pharo-project] Unsubscribing for Announcements I really like Announcements! It's so much easier to update complex GUIs when you can pass state :) I hit one glitch when unsubscribing... The CollaborActive book suggests unsubscribing in #delete. For complex UIs, this doesn't seem to work because #delete is only called for the one morph that was deleted, not for its submorphs (which may need to unsubscribe). I tried this: MyMorph>>delete super delete. "Must come first. Deleting a submorph before self = emergency evaluator" aSubmorphThatNeedsToUnsubscribe delete. SubmorphMentionedAbove>>delete self inventory announcer unsubscribe: self. super delete. But it seems like a lot of work and coupling. Is there no hook that is guaranteed to be called when a morph is going away - i.e. it or a morph in the owner chain is being deleted? Thanks. Sean -- View this message in context: http://forum.world.st/Unsubscribing-for-Announcements-tp3220751p3220751.html Sent from the Pharo Smalltalk mailing list archive at Nabble.com.

Jan. 17, 2011

Re: [Pharo-project] Issue 3542 in pharo: Add SmalltalkImage>>#gcBiasToGrow: and friends to core

by pharo＠googlecode.com

Comment #8 on issue 3542 by philippe...(a)gmail.com: Add SmalltalkImage>>#gcBiasToGrow: and friends to core http://code.google.com/p/pharo/issues/detail?id=3542 I created a Seaside issue for this: http://code.google.com/p/seaside/issues/detail?id=634 Does anybody know whether these settings are also valid for Cog?

Jan. 17, 2011

[Pharo-project] Xtreams-Xtras: hashing and HMAC

by mkobetic＠gmail.com

I started playing with FFI and got the hashing streams working. They require OpenSSL's libcrypto, which should be available on any reasonably recent Unix and OSX. The VW version also has interface to native Windows bcrypt.dll (available on Vista and later) but I haven't done that part yet. Anyway the hashing streams seem to work and performance isn't bad either. Hashing 100MB of ones [ (([ 1 ] reading limiting: 100000000) hashing: 'md5') -= 0; close; digest ] timeToRun takes little over 5 seconds on not particularly fast machine. The above expression runs about 2.5 times faster on VW on the same machine, but that's probably due to the time spent in the block based terminal. Profile on VW says that only about 15% of the time is spent in the hashing layer. Hashing the 21M pharo image is pretty much instant: ((FileDirectory default / 'pharo.image') reading hashing: 'md5') -= 0; close; digest The code is in Xtreams-Xtras and Xtreams-XtrasTests (note that you'll have to load FFI!). I tested it on Pharo 1.2 beta with both cog vm and standard vm. There are few test failures with file terminals that don't seem to like to be closed twice. Should be an easy fix. Enjoy, Martin P.S.: If any resident FFI experts find the time and interest to look over my C bindings and find something wrong, please let me know. In particular I have't quite figured out how to work with struct fields that contain arrays (e.g. 'unsigned char [128]'). I figured out that I can declare the actual size of the field as a third parameter in the #fields declaration, but the accessors generated for the field are not right. I suspect they need to be some form of ExternalData but I don't quite grok how that should be created (see e.g. HMAC_CTX>>key). Also it seems that there isn't a type definition for 'int' so I'm replacing all references to that with 'long'. Is that how it's done?

Jan. 17, 2011

Re: [Pharo-project] Issue 3542 in pharo: Add SmalltalkImage>>#gcBiasToGrow: and friends to core

by pharo＠googlecode.com

Updates: Status: Fixed Comment #7 on issue 3542 by stephane...(a)gmail.com: Add SmalltalkImage>>#gcBiasToGrow: and friends to core http://code.google.com/p/pharo/issues/detail?id=3542 (No comment was entered for this change.)

Jan. 17, 2011