July 2009 - Pharo-dev - lists.pharo.org

[Pharo-project] [ANN] update 10380

by Adrian Lienhard

- isFontAvailable fix - Remove check for higherPerformance in doOneCycleFor: (preference to be removed in a second step) - ClosureTests expectedFailures - MethodFinder, SelectorBrowser, ThreadSafeTranscript - Move JoystickMorph to MorphicExtras package - Remove a couple of references to Squeak in strings (like 'SqueakDebug.log' -> 'PharoDebug.log') - Started implementing ScriptLoader>>#cleanUpForProduction ___________________ http://www.adrian-lienhard.ch/

July 18, 2009

Re: [Pharo-project] fork cleaning in CUIS

by Schwab,Wilhelm K

The example looks very strange to me. Why test the against the active process? Threads are useful because they let us forget about such things: just fork the work at a background priority and let the scheduler handle it - add no small amount of attention to synchronization, of course. I tend to overprotect, so the most common problems I need to find are deadlocks, and they show themselves fairly easily given at tool that shows all callstacks. I have a lot of code that uses #forkAt: and expects to get the process, so I am probably not the most neutral party in this debate. Bill -----Original Message----- From: pharo-project-bounces(a)lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of StÃ©phane Ducasse Sent: Saturday, July 18, 2009 4:58 AM To: An open mailing list to discuss any topics related to an open-source Smalltalk Subject: [Pharo-project] fork cleaning in CUIS 2009/7/17 Andreas Raab <andreas.raab <at> gmx.de>: > Juan Vuletich wrote: >> >> Some might remember >> http://lists.squeakfoundation.org/pipermail/squeak-dev/2008-February/124960… >> . It was a discussion about the dangers of using the result of #fork and >> friends, and the convenience of first creating the process, storing it >> somewhere and later doing #resume. In this release of Cuis, all callers of >> #fork and friends that needed the return value were changed for that >> pattern, and now #fork and friends simply return nil. This is the way to >> avoid those nasty bugs. > > I really like that solution. It's simple and ensures people know what > they're doing. > +1 Good to know that someone put that discussion fruits into a practical plane, even if in own fork :) > Cheers, > - Andreas > > -- Best regards, Igor Stasenko AKA sig. _______________________________________________ Pharo-project mailing list Pharo-project(a)lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

July 18, 2009

Re: [Pharo-project] How to have a faster image

by Schwab,Wilhelm K

Adrian, Sounds good, let's do both. The new image is a nice step forward. Subjectively, it is at least as quick as my heavily hacked image. I started with a web image and have loaded a fair amount of code, so I would want to see the browsers loaded down with Seaside and other big packages that are present in my image. I recommend enabling fast drag by default. Bill -----Original Message----- From: pharo-project-bounces(a)lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of Adrian Lienhard Sent: Saturday, July 18, 2009 8:16 AM To: Pharo-project(a)lists.gforge.inria.fr Subject: Re: [Pharo-project] How to have a faster image Sure, we can also put these preferences on the wiki (what page would be good?). I just wanted to avoid (like Damien), that we *only* put these items on the wiki and then think the problem is solved ;) Cheers, Adrian On Jul 18, 2009, at 15:04 , Schwab,Wilhelm K wrote: > Adrian, > > With respect, I do not understand the resistance to also placing the > recommendations on the Wiki - that might help someone hoping to > postpone updating to a new image. Making a list in a promintent > location in no way prevents improving the downloadable images; let's > do both. > > Bill > > > -----Original Message----- > From: pharo-project-bounces(a)lists.gforge.inria.fr > [mailto:pharo-project-bounces@lists.gforge.inria.fr > ] On Behalf Of Adrian Lienhard > Sent: Saturday, July 18, 2009 1:55 AM > To: Pharo-project(a)lists.gforge.inria.fr > Subject: Re: [Pharo-project] How to have a faster image > > In this thread just preferences were discussed to speed up the tools > (no new packages). > > Instead of adding them to the wiki, I also suggest to make them > default in the Pharo image. Like this people get less features but a > faster GUI, which seems to be preferred from the many recent comments. > If somebody likes more features, he can simply change the preferences > again (maybe adding a note in the workspace would be helpful to > indicate which ones). > > I suggest to change the following: > > SystemBrowser default: OBSystemBrowserAdaptor. > Preferences disable: #dynamicProtocolActivation. > Preferences disable: #annotationPanes > > In this thread it was also suggested to enable > #fastDragWindowForMorphic. Not sure if this is important as we have it > disabled also in the core. > > Damien, what do you think? > > Adrian > > On Jul 18, 2009, at 00:39 , Damien Cassou wrote: > >> On Sat, Jul 18, 2009 at 12:01 AM, StÃ©phane >> Ducasse<stephane.ducasse(a)inria.fr> wrote: >>> I think that pharo (old pharo-dev should contain as less as >>> possible). >> >> Each user means something different by 'as less as possible' (not >> sure it's good english though :-)). You want syntax highlighting and >> completion to be in. IIRC, Michael has no need for them. >> >> -- >> Damien Cassou >> http://damiencassou.seasidehosting.st >> >> "Lambdas are relegated to relative obscurity until Java makes them >> popular by not having them." James Iry >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project _______________________________________________ Pharo-project mailing list Pharo-project(a)lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

July 18, 2009

Re: [Pharo-project] class variable names: initial cap not enforced

by Cameron Sanders

After I gave this response, I found several more emails on the topic. So nobody needs to respond further for my benefit: only respond if there is more that needs to be discussed. Thanks for the info and addressing the matter. Cheers, Cam On Jul 18, 2009, at 9:25 AM, Cameron Sanders wrote: > On Jul 18, 2009, at 3:52 AM, StÃ©phane Ducasse wrote: > >> which version are you using because this was removed at least 2 weeks >> ago? > > So you are questioning Squeak right now, correct (even though this is > the Pharo list).

July 18, 2009

Re: [Pharo-project] class variable names: initial cap not enforced

by Cameron Sanders

Closure VM (Mac 4.1.1beta2U, using Damien's 4.10.2-7179web09.07 image base) with no updates, no patches, no fixes, nothing. Straight out of the box. And by the way, it does feel more responsive (faster) than the Pharo image. (discussed on a different thread.) On Jul 18, 2009, at 3:52 AM, StÃ©phane Ducasse wrote: > which version are you using because this was removed at least 2 weeks > ago? So you are questioning Squeak right now, correct (even though this is the Pharo list). -Cam > > Stef > >> In Pharo, I originally create created the class with this: >> >> Object subclass: #FaFnBasicKeyLabelAssociations >> instanceVariableNames: '' >> classVariableNames: 'theSingleton' >> poolDictionaries: '' >> category: 'FA-FinanceMeta' >> >> And it compiled without complaint in Pharo. >> >> It was Squeak that complained during a load using Monticello. And >> just now, I reverted back to the lower case version (as exampled up >> above) and throws an "Error: theSingleton class variable name should >> be capitalized; proceed to include it anyway" ... and it lets me >> proceed. (I didn't read the full message previously and changed it.) >> So Squeak allows it, but complains where Pharo didn't. >> >> Sounds like it was "by design" in both cases. >> >> (I have three spinoff questions which I will put forth with a >> different subject line.) >> >> Thanks, >> Cam >> >> >> On Jul 17, 2009, at 6:04 PM, StÃ©phane Ducasse wrote: >> >>> this is strange can you show us the class definition. >>> >>> We removed the hard check that >>> enforced that classVariable should be capitalized and instvar >>> starting >>> with a lower case. >>> >>> Lukas wrote some smallLint rules to check that >>> >>> Stef >>> >>> On Jul 17, 2009, at 9:30 PM, Cameron Sanders wrote: >>> >>>> I just loaded the code I have been developing in Pharo into Squeak >>>> (closure VM, using 4.10.2-7179web09.07 image base) and it had one >>>> complaint while loading: >>>> >>>> Squeak (seemingly) requires an initial cap on class variable names. >>>> [Maybe it allows it... but it popped up the debugger on an MC >>>> load.] >>>> >>>> Does Pharo allow the symbol to start with lower case by design, or >>>> was >>>> that act of omission? I am merely raising point to make certain it >>>> is >>>> an act of commission. >>>> >>>> -Cam >>>> >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

July 18, 2009

Re: [Pharo-project] MD5 in pharo?

by Adrian Lienhard

I only talked about incorporating hash functions like MD5. AFAIK these are no problem. Adrian On Jul 18, 2009, at 15:10 , Schwab,Wilhelm K wrote: > Stef, > > What about import/export restrictions? I prefer to leave to other > forums the debate on whether or not goverments (especially mine) has > any business at all restricting such things. However, they do > restrict them, and we might do better to steer clear of > cryptography, or at least make it separately downloadable. > > Bill > > > -----Original Message----- > From: pharo-project-bounces(a)lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr > ] On Behalf Of StÃ©phane Ducasse > Sent: Saturday, July 18, 2009 3:16 AM > To: Pharo-project(a)lists.gforge.inria.fr > Subject: Re: [Pharo-project] MD5 in pharo? > > Yes this is a good idea. > > Stef > > On Jul 18, 2009, at 8:41 AM, Adrian Lienhard wrote: > >> Bill, please note that Esteban just needs a standard hash algorithm. >> No encryption. >> >> Some time ago we discussed including hash functions from Cryptography >> in Pharo core. We postponed it then because it seemed that maybe some >> people would join and make Cryptography work in Pharo. An OpenSSL >> interface would be a very interesting alternative too. >> >> In any case I think we should add M5 and maybe some other hash >> functions to the core. Will add this to my todo list. >> >> Adrian >> >> >> On Jul 18, 2009, at 05:09 , Schwab,Wilhelm K wrote: >> >>> Esteban, >>> >>> IMHO, the correct path is to write an interface for OpenSSL. >>> Ultimately, that should also give us SSL sockets, but long before >>> that, it can provide various hashes and cyphers with very little >>> effort. I am open on whether the interface should be FFI, Alien, or >>> plugin based. One argument for a plugin could come through benefits >>> that _might_ acrue to sockets. I have along way to go on Squeak/ >>> Pharo external interfacing, so I could be way off here(!!), but I am >>> under the impression that plugins can use OS threads, and that could >>> greatly simplify getting OpenSSL to not hang the entire image while >>> waiting on things to happen to/on a socket; that benefit would come >>> at the cost of having to write a plugin. >>> >>> Another option might be to use FFI/Alien to access the cyphers and >>> have a plugin for the SSL sockets. Hopefully someone with Squeak >>> external interfacing experience will tell us "where be the dragons" >>> with the various options. >>> >>> Bill >>> >>> >>> -----Original Message----- >>> From: pharo-project-bounces(a)lists.gforge.inria.fr >>> [mailto:pharo-project-bounces@lists.gforge.inria.fr >>> ] On Behalf Of Esteban Lorenzano >>> Sent: Friday, July 17, 2009 7:25 PM >>> To: pharo-project(a)lists.gforge.inria.fr >>> Subject: [Pharo-project] MD5 in pharo? >>> >>> Hi, >>> Some time ago, I read a thread about cryotography, and as far as I >>> remember, some body says about integrate the basic algoritms (MD5 >>> and >>> maybe others) as part of the pharo core. >>> Well... now I need to use MD5 and cryptography package is not >>> working >>> well (it opens a debugger each time I save my image). >>> >>> I wonder if there are another package with MD5? >>> >>> Cheers, >>> Esteban >>> >>> >>> >>> _______________________________________________ >>> Pharo-project mailing list >>> Pharo-project(a)lists.gforge.inria.fr >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>> >>> _______________________________________________ >>> Pharo-project mailing list >>> Pharo-project(a)lists.gforge.inria.fr >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

July 18, 2009

Re: [Pharo-project] New much faster Pharo based on 10379

by Schwab,Wilhelm K

Stef, I think you are making a very good case for the wiki page on feartures and performance. Some of these tradeoffs are too individual to be properly addressed in a few downloads. Bill -----Original Message----- From: pharo-project-bounces(a)lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of StÃ©phane Ducasse Sent: Saturday, July 18, 2009 3:29 AM To: Pharo-project(a)lists.gforge.inria.fr Subject: Re: [Pharo-project] New much faster Pharo based on 10379 can you disable the annotation pane too? Could you also load the packageBrowser so that we can pick the other one too? May be put also the highPerformance on I would also remove the optional buttons because they just take space. (You see I can also be dogmatic). I imgaine that the roundcorner could be disable too to gain some cycles too. Stef On Jul 18, 2009, at 8:55 AM, Damien Cassou wrote: > I've just uploaded a new Pharo image. It is much faster now, but you > won't get the package browsing (only the category browsing). > > http://pharo-project.org/pharo-download > > For all the people who found Pharo slow, please tell me what you think > of this one ! > > -- > Damien Cassou > http://damiencassou.seasidehosting.st > > "Lambdas are relegated to relative obscurity until Java makes them > popular by not having them." James Iry > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project _______________________________________________ Pharo-project mailing list Pharo-project(a)lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

July 18, 2009

Re: [Pharo-project] How to have a faster image

by Adrian Lienhard

Sure, we can also put these preferences on the wiki (what page would be good?). I just wanted to avoid (like Damien), that we *only* put these items on the wiki and then think the problem is solved ;) Cheers, Adrian On Jul 18, 2009, at 15:04 , Schwab,Wilhelm K wrote: > Adrian, > > With respect, I do not understand the resistance to also placing the > recommendations on the Wiki - that might help someone hoping to > postpone updating to a new image. Making a list in a promintent > location in no way prevents improving the downloadable images; let's > do both. > > Bill > > > -----Original Message----- > From: pharo-project-bounces(a)lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr > ] On Behalf Of Adrian Lienhard > Sent: Saturday, July 18, 2009 1:55 AM > To: Pharo-project(a)lists.gforge.inria.fr > Subject: Re: [Pharo-project] How to have a faster image > > In this thread just preferences were discussed to speed up the tools > (no new packages). > > Instead of adding them to the wiki, I also suggest to make them > default in the Pharo image. Like this people get less features but a > faster GUI, which seems to be preferred from the many recent comments. > If somebody likes more features, he can simply change the > preferences again (maybe adding a note in the workspace would be > helpful to indicate which ones). > > I suggest to change the following: > > SystemBrowser default: OBSystemBrowserAdaptor. > Preferences disable: #dynamicProtocolActivation. > Preferences disable: #annotationPanes > > In this thread it was also suggested to enable > #fastDragWindowForMorphic. Not sure if this is important as we have > it disabled also in the core. > > Damien, what do you think? > > Adrian > > On Jul 18, 2009, at 00:39 , Damien Cassou wrote: > >> On Sat, Jul 18, 2009 at 12:01 AM, StÃ©phane >> Ducasse<stephane.ducasse(a)inria.fr> wrote: >>> I think that pharo (old pharo-dev should contain as less as >>> possible). >> >> Each user means something different by 'as less as possible' (not >> sure >> it's good english though :-)). You want syntax highlighting and >> completion to be in. IIRC, Michael has no need for them. >> >> -- >> Damien Cassou >> http://damiencassou.seasidehosting.st >> >> "Lambdas are relegated to relative obscurity until Java makes them >> popular by not having them." James Iry >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

July 18, 2009

Re: [Pharo-project] Pharo apparently slow on linux

by Adrian Lienhard

These actions are in the submenu "extended search". HTH, Adrian On Jul 18, 2009, at 15:00 , Schwab,Wilhelm K wrote: > They might be (I'll have to use them for a while), though I would > still like to see especially the browse command along side of > evaluate/inspect/explore in the menus. > > Thanks, > > Bill > > > > > -----Original Message----- > From: pharo-project-bounces(a)lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr > ] On Behalf Of Adrian Lienhard > Sent: Saturday, July 18, 2009 1:46 AM > To: Pharo-project(a)lists.gforge.inria.fr > Subject: Re: [Pharo-project] Pharo apparently slow on linux > > > On Jul 18, 2009, at 08:02 , Schwab,Wilhelm K wrote: > >> Laurent, >> >> I will preface this by saying that I have had a fairly intense week >> with Pharo. I am closing in on a solution to a real problem. I >> greatly miss Dolphin's Browse-it command, and its F12 and shift-F12 >> (definitions/references to a typed selector); the message search has >> its points, but it takes some extra steps to use in comparison to the >> Dolphin features. > > Isn't Ctrl-b (browse selected class name), Ctrl-m (implementors of > selector), Ctrl-n (senders of selector), and Ctrl-shift-n (class > references) doing the same? I almost never use the message search > but always these shortcuts. > > Adrian > >> Back to the topic at hand; let's see if I am following. Start with a >> core image, run a script that installs what looks like a Pharo web >> image, makes a few changes to settings in favor of speed, and you get >> something that you find faster than Pharo?? Did you make the same >> speed selections in Pharo? If so, one wonders what happened between >> core and Pharo-dev/web that Lukas did not do to the core image. >> >> Sorry if I'm off base here - it's been a long and very good few days. >> >> Bill >> >> >> ________________________________ >> From: pharo-project-bounces(a)lists.gforge.inria.fr >> [mailto:pharo-project-bounces@lists.gforge.inria.fr >> ] On Behalf Of laurent laffont >> Sent: Saturday, July 18, 2009 12:45 AM >> To: Pharo-project(a)lists.gforge.inria.fr >> Subject: Re: [Pharo-project] Pharo apparently slow on linux >> >> >> On Fri, Jul 17, 2009 at 8:31 PM, StÃ©phane Ducasse >> <stephane.ducasse(a)inria.fr <mailto:stephane.ducasse@inria.fr>> wrote: >> Hi >> >> David shaffer reported to me in fuzzy way that pharo is slow on >> linux. >> Dear linux users can you report if you experienced the same and on >> which >> machine >> distributions >> vm >> image >> >> please compare the core and the dev (with browser usage) >> >> _______________________________________________ >> >> Hi, >> >> machine: core duo 2.0 GHz, 1 GB RAM (White Macbook, 2007) >> distribution: Archlinux >> vm: exupery pharo-vm-0.15.1b-linux.zip >> images: pharo0.1-10373dev09.07.2 and latest Pharo-Core >> >> Pharo-Core: (System Browser) >> - startup time: instantaneous >> - navigate randomly in browser: 3% - 8% CPU usage >> - find class OrderedCollection: ~10% CPU >> - browse senders of add: time to open 1s, 21% CPU >> >> Pharo-Dev: (Package Browser) >> - statup time: 3s (cold start 5s) >> - navigate randomly in browser: 9% - 15% CPU usage >> - find class OrderedCollection: ~13% CPU >> - browse senders of add: time to open 19s, 48% CPU >> >> Now I'm using Pharo-Core with Luka's scripts >> (http://code.google.com/p/pharo/wiki/ImageBuildScripts >> ) as it's far more pleasant to use for me. >> >> Laurent >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

July 18, 2009

Re: [Pharo-project] MD5 in pharo?

by Schwab,Wilhelm K

Stef, What about import/export restrictions? I prefer to leave to other forums the debate on whether or not goverments (especially mine) has any business at all restricting such things. However, they do restrict them, and we might do better to steer clear of cryptography, or at least make it separately downloadable. Bill -----Original Message----- From: pharo-project-bounces(a)lists.gforge.inria.fr [mailto:pharo-project-bounces@lists.gforge.inria.fr] On Behalf Of StÃ©phane Ducasse Sent: Saturday, July 18, 2009 3:16 AM To: Pharo-project(a)lists.gforge.inria.fr Subject: Re: [Pharo-project] MD5 in pharo? Yes this is a good idea. Stef On Jul 18, 2009, at 8:41 AM, Adrian Lienhard wrote: > Bill, please note that Esteban just needs a standard hash algorithm. > No encryption. > > Some time ago we discussed including hash functions from Cryptography > in Pharo core. We postponed it then because it seemed that maybe some > people would join and make Cryptography work in Pharo. An OpenSSL > interface would be a very interesting alternative too. > > In any case I think we should add MD5 and maybe some other hash > functions to the core. Will add this to my todo list. > > Adrian > > > On Jul 18, 2009, at 05:09 , Schwab,Wilhelm K wrote: > >> Esteban, >> >> IMHO, the correct path is to write an interface for OpenSSL. >> Ultimately, that should also give us SSL sockets, but long before >> that, it can provide various hashes and cyphers with very little >> effort. I am open on whether the interface should be FFI, Alien, or >> plugin based. One argument for a plugin could come through benefits >> that _might_ acrue to sockets. I have along way to go on Squeak/ >> Pharo external interfacing, so I could be way off here(!!), but I am >> under the impression that plugins can use OS threads, and that could >> greatly simplify getting OpenSSL to not hang the entire image while >> waiting on things to happen to/on a socket; that benefit would come >> at the cost of having to write a plugin. >> >> Another option might be to use FFI/Alien to access the cyphers and >> have a plugin for the SSL sockets. Hopefully someone with Squeak >> external interfacing experience will tell us "where be the dragons" >> with the various options. >> >> Bill >> >> >> -----Original Message----- >> From: pharo-project-bounces(a)lists.gforge.inria.fr >> [mailto:pharo-project-bounces@lists.gforge.inria.fr >> ] On Behalf Of Esteban Lorenzano >> Sent: Friday, July 17, 2009 7:25 PM >> To: pharo-project(a)lists.gforge.inria.fr >> Subject: [Pharo-project] MD5 in pharo? >> >> Hi, >> Some time ago, I read a thread about cryotography, and as far as I >> remember, some body says about integrate the basic algoritms (MD5 and >> maybe others) as part of the pharo core. >> Well... now I need to use MD5 and cryptography package is not working >> well (it opens a debugger each time I save my image). >> >> I wonder if there are another package with MD5? >> >> Cheers, >> Esteban >> >> >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project _______________________________________________ Pharo-project mailing list Pharo-project(a)lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

July 18, 2009