- Pharo-dev - lists.pharo.org

Re: [Pharo-project] Squeaksource down again

by Fabrizio Perin

Well, all our servers are down. Try tommorow. 2012/1/16 Frank Shearar <frank.shearar(a)gmail.com> > http://www.downforeveryoneorjustme.com/www.squeaksource.com > > Hooray for ss3.gemstone.com! > > frank > >

Jan. 16, 2012

[Pharo-project] Squeaksource down again

by Frank Shearar

http://www.downforeveryoneorjustme.com/www.squeaksource.com Hooray for ss3.gemstone.com! frank

Jan. 16, 2012

Re: [Pharo-project] [COTDC] 105 - ZipConstants

by Ben Coman

sean(a)clipperadams.com wrote: > 104 classes done > 793 classes remaining > Continuing in Compression... > > Today: ZipConstants > > > Comment Of The Day Contest - One Day One Comment > Rules: > #1: Each day a not commented class is elected. Each day the best comment will be integrated with name of the author(s). > #2: If you cannot comment it, deprecate it. > Results: http://code.google.com/p/pharo/wiki/CommentOfTheDayContest > > p.s. this message was sent from a pharo image. Did you know you could easily do that?! > > > This class defines magic numbers taken from RFC1951 [1b], and also possibly RFC1950 [1a] & RFC1952 [1c]. It presets some dictionary structures as described at [1a] 8.1. A class can import these bindings as 'class variables' by including the following in its class definition: poolDictionaries: 'ZipFileConstants' Following are source references to these constants contained within several class side initialization methods. (These might be better spread through out those methods as time permits) initializeDeflateConstants WindowSize [2e]"w_size", [2a]"windowBits is the base two logarithm of windowSize where default windowBits=15" WindowMask [2e]"w_mask" MaxDistance [2e]"MAX_DIST" MinMatch [2c] MaxMatch [2c] HashBits [2e]"hash_bits" HashMask [2e]"hash_mask" HashShift [2e]"hash_shift" initializeDistanceCodes BaseDistance [2f] DistanceCodes [2f] initializeExtraBits ExtraLengthBits [1]3.2.5, [2b] ExtraDistanceBits [1]3.2.5, [2b] ExtraBitLengthBits [2b] BitLengthOrder [1]3.2.7, [2b] initializeFixedTrees [1]3.2.6 initializeWriteStreamConstants MaxBits [2d] MaxBitLengthBits [2b] EndBlock [2b] StoredBlock [2c] FixedBlock [2c] DynamicBlock [2c] [1]3.2.3"BTYPE" NumLiterals MaxLengthCodes [2e] MaxDistCodes [2e] MaxBitLengthCodes [2e] MaxLiteralCodes Repeat3To6 [2b] Repeat3To10 [2b] Repeat11To138 [2b] [1a] "ZLIB Compressed Data Format Specification version 3.3" http://www.ietf.org/rfc/rfc1950.txt [1b] "DEFLATE Compressed Data Format Specification version 1.3" http://www.ietf.org/rfc/rfc1951.txt [1c] "GZIP file format specification version 4.3" http://www.ietf.org/rfc/rfc1952.txt [2] ZLIB Source Code http://zlib.net/zlib-1.2.5.tar.gz [2a] zlib.h [2b] trees.c [2c] zutil.h [2d] inftrees.c [2e] deflate.h [2f] trees.h

Jan. 16, 2012

Re: [Pharo-project] Speeding up Finder string search

by Stefan Marr

Hi: On 16 Jan 2012, at 14:31, Camillo Bruni wrote: > I guess having the sources completely in the image is the straight-forward solution to this :/ Well, we could also cache just the resulting source string. Not sure what that means in terms of memory, but going to the file every time a method is asked for its code seems to be very naive. How does Ring do it? > or using a native tool to grep the source files and then use the results to map back to the methods Ehm, that sounds very brittle, except if you got a nice file representation of your code of course ;) Levente pointed out to me that he introduced a smarter approach to caching in Squeak, with similar performance improvements, and he was thinking about improving that to a process-local variable. Perhaps also an option. Best regards Stefan -- Stefan Marr Software Languages Lab Vrije Universiteit Brussel Pleinlaan 2 / B-1050 Brussels / Belgium http://soft.vub.ac.be/~smarr Phone: +32 2 629 2974 Fax: +32 2 629 3525

Jan. 16, 2012

Re: [Pharo-project] Speeding up Finder string search

by Camillo Bruni

I guess having the sources completely in the image is the straight-forward solution to this :/ or using a native tool to grep the source files and then use the results to map back to the methods cami On 2012-01-15, at 18:54, Benjamin wrote: > Thanks for having a look at this problem. > > With Camillo, we though about using parallel processes but never go further than an idea :) > > > Ben > > On Jan 15, 2012, at 6:11 PM, Stefan Marr wrote: > >> Hi: >> >> The finder is annoyingly slow when doing string searches. >> Compared to a 'grep' its multiple magnitudes slower, at least from my perception :( >> >> Profiling pointed my at RemoteString>>string and its use of readOnlyCopy on the SourceFiles. >> >> I put a cache of these read only files into ExpandedSourceFileArray and get a nice speedup. >> >> { [ Finder new constructSourceDictionary ] timeToRun. >> [ Finder new constructSourceDictionary ] timeToRun. >> [ Finder new constructSourceDictionary ] timeToRun . } >> >> Without Cache: #(32079 29034 32274) >> With Cache: #(10757 10718 11050) >> >> >> While that works for the searching, it does fall apart for other uses of RemoteString>>string. (For instance, filing out the changes...) >> >> >> If anyone has an idea how to avoid the overhead of copying, I would be all ears. >> >> >> Thanks >> Stefan >> >> -- >> Stefan Marr >> Software Languages Lab >> Vrije Universiteit Brussel >> Pleinlaan 2 / B-1050 Brussels / Belgium >> http://soft.vub.ac.be/~smarr >> Phone: +32 2 629 2974 >> Fax: +32 2 629 3525 >> >> > >

Jan. 16, 2012

Re: [Pharo-project] New IDE alternative (was Misc. newbie questions)

by Frank Shearar

On 16 January 2012 09:59, Lawson English <lenglish5(a)cox.net> wrote: > On 1/15/12 6:44 PM, Jimmie Houchin wrote: >> >> On 1/15/2012 6:55 AM, Gerry Weaver wrote: >>> >>> Hi Andreas, >>> >>>> I am not comfortable with the idea to write parts of an application in >>>> different languages. >>>> Typically the disadvantages overweigh the advantages to do so as you >>>> would have different languages and systems to master and update. >>>> Interoperability with other systems and languages should be easy and >>>> Squeak/Pharo are still lacking in this area. This is well known and >>>> hopefully there will be some improvements in the future. >>> >>> >>> I guess I would have to disagree with you here. Most of the editors and >>> IDEs of other languages are not maintained by the language proper. There >>> are many editors and IDEs that support many languages in addition to the >>> one they are written in. I think the benefits of using a full featured >>> GUI toolkit to create an IDE would be significant. >> >> >> And I have to disagree with you here. You lack the imagination and >> knowledge to understand the significant advantage of having a single >> language, environment and toolset that Smalltalk provides. > > > I agree that there is an advantage to having a unified IDE/environment/etc, > but Smalltalk IS stuck in the past in that it doesn't take advantage of > multiple cores. I'm not talking about multi-threading in the usual sense, > but things like the ability to debug one image from another so that the > errors that pop up in the application under development don't affect the > environment being used TO development that application. This issue pops up > most obviously when trying to debug Cobalt/Croquet in a multi-user > configuration, but arises all the time, especially when external libraries > (e.g. OpenGL) are being used and errors occur that the current toolset isn't > designed to accommodate. > > We need to develop better ways of doing things, both for individual and > collaborative environments. IOW, we need spoon and teatime and various other > solutions to mature and work together. If only we knew some folks working on the problem... http://marcusdenker.de/publications/Casa09aObjectSpaces.pdf :) Of course, there's a bit of elbow grease required to turn a research topic into a production-ready system. frank

Jan. 16, 2012

Re: [Pharo-project] New IDE alternative (was Misc. newbie questions)

by Lawson English

On 1/15/12 6:44 PM, Jimmie Houchin wrote: > On 1/15/2012 6:55 AM, Gerry Weaver wrote: >> Hi Andreas, >> >>> I am not comfortable with the idea to write parts of an application in >>> different languages. >>> Typically the disadvantages overweigh the advantages to do so as you >>> would have different languages and systems to master and update. >>> Interoperability with other systems and languages should be easy and >>> Squeak/Pharo are still lacking in this area. This is well known and >>> hopefully there will be some improvements in the future. >> >> I guess I would have to disagree with you here. Most of the editors and >> IDEs of other languages are not maintained by the language proper. There >> are many editors and IDEs that support many languages in addition to the >> one they are written in. I think the benefits of using a full featured >> GUI toolkit to create an IDE would be significant. > > And I have to disagree with you here. You lack the imagination and > knowledge to understand the significant advantage of having a single > language, environment and toolset that Smalltalk provides. I agree that there is an advantage to having a unified IDE/environment/etc, but Smalltalk IS stuck in the past in that it doesn't take advantage of multiple cores. I'm not talking about multi-threading in the usual sense, but things like the ability to debug one image from another so that the errors that pop up in the application under development don't affect the environment being used TO development that application. This issue pops up most obviously when trying to debug Cobalt/Croquet in a multi-user configuration, but arises all the time, especially when external libraries (e.g. OpenGL) are being used and errors occur that the current toolset isn't designed to accommodate. We need to develop better ways of doing things, both for individual and collaborative environments. IOW, we need spoon and teatime and various other solutions to mature and work together. L.

Jan. 16, 2012

Re: [Pharo-project] [Pharo-users] OCompletion configuration for 1.4

by Luc Fabresse

yes. Thanks Guillermo! Luc 2012/1/15 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> > Thanks thanks thanks and â¦ thanks > > Stef > On Jan 13, 2012, at 10:53 PM, Mariano Martinez Peck wrote: > > > Thanks Guille. It works perfect. I have just commited a small fix in > Ocompletion-MarianoMartinezPeck.114 ;) > > > > cheers > > > > On Fri, Jan 13, 2012 at 10:34 PM, Igor Stasenko <siguctua(a)gmail.com> > wrote: > > On 13 January 2012 17:24, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> > wrote: > > > Thanks a lot!!!! > > > > > yeah, i just checked and it works out of the box. good job! > > > > > Stef > > > > > > On Jan 13, 2012, at 3:53 PM, Guillermo Polito wrote: > > > > > >> I've written a new version of OCompletion for 1.4 with several fixes > and compatibility additions for Pharo 1.4 > > >> > > >> Gofer it > > >> squeaksource: 'MetacelloRepository'; > > >> package: 'ConfigurationOfOCompletion'; > > >> load. > > >> > > >> ConfigurationOfOCompletion loadStable > > >> > > >> If someone wants to try it :). > > >> > > >> Guille > > > > > > > > > > > > > > -- > > Best regards, > > Igor Stasenko. > > > > > > > > > > -- > > Mariano > > http://marianopeck.wordpress.com > > > > >

Jan. 16, 2012

Re: [Pharo-project] startup errors

by Andrea BrÂÃ¼hlmann

Hi there, Could anyone please have a look at issue 5045? I am running into big troubles from time to time because of images that cannot be opened anymore because there happens an error somewhere during startup. The discussed option would allow image recovery without hacking the bytecode! Thanks Andrea Andrea BrÂÃ¼hlmann schrieb: > I tested it a bit in a fresh 1.3 image and opened the issue 5045, > maybe we can continue the discussion there. The feature would be great! > > Andrea > > > > Igor Stasenko schrieb: >> On 26 October 2011 11:51, Andrea BrÃ¼hlmann <a.bruehlmann(a)netstyle.ch> >> wrote: >> >>> I tried it with this option now, but it did not solve the problem, >>> because >>> it just saved a new version of the image and quit, but did not open a >>> debugger. Opening the new version does the same as the original. Did >>> I miss >>> something? >>> >>> >> It should open a debugger. if not, then this is a bug :) >> It might be, that if error happens in startup phase, then it is not >> opens a debugger. >> >> >>> I would appreciate a command line option that either opens a >>> debugger or >>> ignores the errors, because like this you usually have a clean image >>> but if >>> you have a problem, you can open the image and do something. >>> >>> Andrea >>> >>> Igor Stasenko schrieb: >>> >>>> On 25 October 2011 23:26, Schwab,Wilhelm K <bschwab(a)anest.ufl.edu> >>>> wrote: >>>> >>>>> Sig, >>>>> >>>>> All too true, and very pure. But what if I just want to save a >>>>> package, >>>>> or some data, that might be locked away in the image? Code is >>>>> generally >>>>> safe, since one can recover lost changes into a healthy image, but >>>>> there can >>>>> still be other data lurking in an image. >>>>> >>>>> A middle-ground approach would be to have command line option that >>>>> lets >>>>> the image run. One should run w/o it to bring errors to >>>>> attention, but at >>>>> least it would be possible to override and at least have an >>>>> opportunity to >>>>> recover endangered bits. >>>>> >>>>> >>>> look at settings, there's already an option to save a new version of >>>> image before quit. >>>> if you turn this option on, then any unhandled error will open a >>>> debugger if you open an image saved in such state. >>>> >>>> >>>>> Bill >>>>> >>>>> >>>>> ________________________________________ >>>>> 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: Tuesday, October 25, 2011 9:40 AM >>>>> To: Pharo-project(a)lists.gforge.inria.fr >>>>> Subject: Re: [Pharo-project] startup errors >>>>> >>>>> On 24 October 2011 11:40, Andrea BrÃ¼hlmann <a.bruehlmann(a)netstyle.ch> >>>>> wrote: >>>>> >>>>>> It seems that pharo 1.3 introduced that the image quits if an error >>>>>> happens >>>>>> during startup. What are the reasons for this? >>>>>> >>>>>> >>>>> The reasons are simple: >>>>> if image fails to startup properly, there are no way to tell, if some >>>>> services initialized properly or not (UI is one of them), >>>>> and so, there are no any guarantees that image could run safely. >>>>> So, the best thing which you can do is to write error to log and >>>>> quit. >>>>> >>>>> This is because startup manager knows what to start-up and in what >>>>> order, but it doesn't knows, how critical a given service for >>>>> properly >>>>> running the whole image. Therefore, if you don't handle startup >>>>> errors >>>>> in your service code, a startup manager has no other choice , but >>>>> just >>>>> leave to OS. >>>>> >>>>> >>>>> >>>>>> Or what's the state of the email below? >>>>>> >>>>>> Andrea >>>>>> >>>>>> >>>>>> Camillo Bruni schrieb: >>>>>> >>>>>>> While working on Coral we encountered a rather annoying behavior of >>>>>>> pharo >>>>>>> images when starting up. >>>>>>> >>>>>>> We wanted to check if we can debug the CoralScriptLoader, but of >>>>>>> corse >>>>>>> since this happens at image startup time this is not a good ideaâ¦ >>>>>>> HOWEVER we >>>>>>> were no longer able to run the image as it immediately crashes >>>>>>> during >>>>>>> the >>>>>>> startup. >>>>>>> >>>>>>> Now I wonder if it would make sense to add a couple of on:do: in >>>>>>> SmalltalkImage >> snapshot:anQuit: to collect the errors of all the >>>>>>> startup >>>>>>> scripts and then only show them after all other startupListItems >>>>>>> are >>>>>>> processed. >>>>>>> >>>>>>> All in all the behavior would not much differ from what is going on >>>>>>> right >>>>>>> now, but would prevent stupid users like me from losing a whole >>>>>>> image. >>>>>>> >>>>>>> camillo >>>>>>> >>>>>>> >>>>> -- >>>>> Best regards, >>>>> Igor Stasenko. >>>>> >>>>> >>>>> >>>>> >>>> >>>> >>> -- >>> AB | ANDREA BRÃHLMANN Â· SOFTWARE ENGINEER >>> | NETSTYLE Â· TERRASSENWEG 18 Â· CH-3012 BERN >>> | TEL +41 31 356 42 54 Â· FAX +41 31 356 42 51 >>> | WWW.NETSTYLE.CH Â· A.BRUEHLMANN(a)NETSTYLE.CH >>> >>> >>> >> >> >> >> > > >

Jan. 16, 2012

Re: [Pharo-project] [Iliad] [ANN] Amber Smalltalk 0.9.1 is out!

by laurent laffont

Nice work guys ! Laurent On Mon, Jan 16, 2012 at 1:06 AM, Nicolas Petton <petton.nicolas(a)gmail.com>wrote: > About 4 moons have passed and Amber - the Smalltalk for the web - has > during that time moved forward quite a lot. Since the 0.9 release back > in september we have made about 250 commits and closed 52 issues of > about 75 reported during these months. > > Now with over 43 forks on github and more than 230 followers the > project: > > http://www.amber-lang.net > > ...is live and kicking! > > A lot of cool stuff is being done in those forks and not in the master > repository, like for example the gaming framework called Ludus by > Bernat > Romagosa: > > https://github.com/bromagosa/amber/tree/ludus > > ...or Ambrhino by Stefan Krecher - Amber running in Rhino: > > https://github.com/StefanKrecher/Ambrhino > > So, why would you take a look at Amber? > > In our opinion Amber is perfectly positioned for the HTML5 onslaught > and > the explosion of all-things-javascript like for example Nodejs. > > Amber plays very well with others and can seamlessly use Javascript > libraries! It's a *real* Smalltalk, the environment is all there > including Workspace, Transcript, Browser, > senders/implementors/references to class, TestRunner, Inspectors, code > editing with syntax coloring and a Debugger. There is no image or > interpreter, all compilation is incremental. > > JavaScript is quite a broken language with lots of traps and odd > quirks. > It is the assembler of the Internet and we love it for that, but we > don't want to write applications in it. Smalltalk is immensely cleaner, > both syntactically and semantically with a simple class model and a > lightweight syntax for closures. It is in many ways a perfect match for > the Good Parts of JavaScript. > > And having a true live interactive incremental development environment > where you can build your application directly in the browser is > unbeatable... > > > Below follows a summary of the major changes since release 0.9. We hope > you join us in developing Amber and having fun! Fork at github, join in > #amber-lang on freenode and hop onto the mailing list. > > regards, Nicolas & GÃ¶ran ...and a BIG thanks to everyone that are > involved in the project! > --------------------------------------------- > > Here's a summary of changes since the 0.9 release: > > - 80 new unit tests written > - 52 issues fixed > - All classes in Kernel-Objects, Kernel-Classes and Kernel-Methods has > been documented > - New documentation framework (see > http://amber-lang.net/documentation.html) > - Better class organisations, "Kernel" package split into several > packages > - First class packages have replaced class categories > - Internet Explorer 7+ compatibility > - New Announcement framework ported from Pharo > - New console-based REPL written in Amber using node.js > - Symbol class implemented together with object identity and #== > - New OrderedCollection and Set implementation > - Dictionary can now have any kind of object as keys. String-key > dictionary has been renamed HashedCollection > - New TwitterWall example > - Improved HTML Canvas, now compatible with IE7 > - Improved JSObjectProxy for seemless JavaScript objects access from > Amber > - No more jQuery binding. Amber is fully capable of sending messages to > JavaScript objects > > >

Jan. 16, 2012