- Pharo-dev - lists.pharo.org

Re: [Pharo-project] Streams. Status and where to go?

by Levente Uzonyi

On Sat, 27 Feb 2010, Richard Durr wrote: > So what speaks against using VisualWorks' Xtreams? > http://www.cincomsmalltalk.com/blog/blogView?entry=3444278480&printTitle=Sm… 1. Someone has to port it. 2. It's optimized for VW, so the ported code's performance will probably be bad. Levente > > On Fri, Feb 26, 2010 at 11:01 PM, Igor Stasenko <siguctua(a)gmail.com> wrote: >> On 26 February 2010 21:30, Nicolas Cellier >> <nicolas.cellier.aka.nice(a)gmail.com> wrote: >>> 2010/2/26 Igor Stasenko <siguctua(a)gmail.com>: >>>> On 26 February 2010 18:59, Nicolas Cellier >>>> <nicolas.cellier.aka.nice(a)gmail.com> wrote: >>>>> 2010/2/26 Igor Stasenko <siguctua(a)gmail.com>: >>>>>> Hello, Nicolas. >>>>> >>>>> Hi igor. >>>>> You should load it in trunk. >>>>> >>>> Ah, i think my image is a bit outdated then. >>>> >>>>>> I want to try it out. >>>>>> I tried to load it (XTream-Core) into my image, and it bug me about >>>>>> unresolved dependencies: >>>>>> ---- >>>>>> This package depends on the following classes: >>>>>> Â ByteTextConverter >>>>>> You must resolve these dependencies before you will be able to load >>>>>> these definitions: >>>>>> Â ByteTextConverter>>nextFromXtream: >>>>>> Â ByteTextConverter>>nextPut:toXtream: >>>>>> Â ByteTextConverter>>readInto:startingAt:count:fromXtream: >>>>>> ---- >>>>>> I ignored these warnings, pressing continue, and here what it warns >>>>>> about in my trunk image: >>>>>> >>>>>> TextConverter>>next:putAll:startingAt:toXtream: (latin1Map is Undeclared) >>>>>> TextConverter>>next:putAll:startingAt:toXtream: (latin1Encodings is Undeclared) >>>>>> TextConverter>>readInto:startingAt:count:fromXtream: (latin1Map is Undeclared) >>>>>> >>>>>> Is ByteTextConverter a Pharo-specific class? >>>>>> >>>>> >>>>> This is a refactoring of TextConverter I made in trunk. >>>>> Pharo did the same before me (it comes from Sophie), but I missed it >>>>> unfortunately... >>>>> >>>>>> If you seen my previous message, i think you noticed that >>>>>> XXXTextConverter is abdominations (IMO), and should be reimplemented >>>>>> as a wrapping-streams instead. >>>>>> Would you be willing to change that in XStreams? I mean implementing a >>>>>> conversion streams model, which can wrap around any other stream, >>>>>> like: >>>>>> >>>>>> myStream := UTFReaderStream on: otherStream. >>>>>> myString := myStream contents. >>>>>> >>>>>> or using other way: >>>>>> >>>>>> myString := (someBaseStream wrapWith: UTFReaderStream) contents. >>>>>> >>>>>> or.. >>>>>> myDecodedString := (someBaseStream wrapWith: (DecodingStreams >>>>>> decoderFor: myEncoding) contents. >>>>>> >>>>>> That's would be much nicer than using converters. >>>>> >>>>> Currently, I have a ConverterReadXtream and a ConverterWriteXtream >>>>> which are stream wrappers. >>>>> They use old TextConverter to do the real job, but I agree, a full >>>>> rewrite of this one is needed. >>>>> However, I would like to keep these two layers for Stream composition: >>>>> - the generic converter stream >>>>> - the conversion algorithm >>>>> >>>> >>>> Why? >>>> In your implementation you already added the >>>> readInto: aCollection startingAt: startIndex count: anInteger >>>> and >>>> next: count into: aString startingAt: startIndex >>>> into converters, which makes them even more like streams. >>>> >>> >>> Yes, you may be right. >>> Maybe my ratio innovating/reusing was a bit low :) >>> >>>> So, what stopping you from making an abstract, generic XtreamWrapper class, >>>> and then a number of subclasses Â (LatinConversionStream , >>>> UnicodeConversionStream etc), >>> >>> Yes, that's possible. But it's already what ConverterReadXtream and >>> ConverterWriteXtream are. >>> >> >> I suggesting to use a following hierarchy >> >> Xtream -> XtreamWrapper -> ConverterXtream -> (bunch of subclasses) >> >> or just >> >> Xtream -> XtreamWrapper -> (bunch of subclasses) >> >> since i don't think there a lot of specific behavior in >> ConverterXtream worth creating a separate class. >> But maybe i'm wrong. >> >>>> as well as BufferedWrapper? >>>> >>> >>> BufferedReadXtream and BufferedWriteXtream already are generic. It's >>> just that I have separated read and write... >>> So you will find ReadXtream>>buffered >>> Â Â Â Â ^(BufferedReadXtream new) >>> Â Â Â Â Â Â Â Â contentsSpecies: self contentsSpecies bufferSize: self preferredBufferSize; >>> Â Â Â Â Â Â Â Â source: self >>> >>> Or do you mean a single Buffer for read/write ? >>> That would look more like original VW I think. >>> >> >> obviously, if you reading and writing to same stream , you should take >> care of keeping any buffered i/o in sync. >> The #buffered can decide what kind of stream to create >> self isWritable ifTrue: [ create R/W wrapper ] ifFalse: [ create R/O wrapper ] >> >> this is , of course if you promote #buffered to Xtream class. Which i >> think worthful thing. >> >>>> So, it will cost us 1 less message dispatch in >>>> a := stream next. >>>> >>>> In your model you having: >>>> >>>> (converter stream) -> (converter) -> basic stream >>>> >>>> while if using wrapper it will be just: >>>> (converter wrapper) -> basic stream >>>> >>> >>> I must re-think why I made this decision of additional indirection... >>> Maybe it was just reusing... >>> >> >> I think this is just about reuse. But as i shown in >> UFT8TextConverter>>nextFromStream: >> its in addition to extra dispatch, using a characters instead of >> bytes, which can be avoided >> if you wrap the stream to be converted and tell it to work in binary >> mode, since your wrapper are in control. >> >>>> >>>>> Though current XTream is a quick hack reusing Yoshiki TextConverter, >>>>> it already demonstrates possible gains coming from buffering. >>>>> The speed comes from,applying utf8ToSqueak, squeakToUtf8 trick: copy >>>>> large ASCII encoded portions verbatim. >>>>> This works very well with squeak source because 99,99% of characters are ASCII. >>>>> >>>>>> >>>>>> Wrappers is more flexible comparing to TextConverters, since they are >>>>>> not obliged to convert to/from text-based collections only. >>>>>> For example, we can use same API for wrapping with ZIP stream: >>>>>> >>>>>> myUnpackedData := (someBaseStream wrapWith: ZIPReaderStream) contents. >>>>>> >>>>>> and many other (ab)uses.. Like reading changeset chunks: >>>>>> >>>>>> nextChunk := (fileStream wrapWith: ChunkReaderStream) next. >>>>>> >>>>> >>>>> Yes, that fits my intentions. >>>>> What I want is to preserve buffered operations along the chain, and >>>>> avoid byte-by-byte conversions when possible. >>>>> >>>> >>>> Buffering is just a wrapper. Btw, again, why you don't providing a >>>> generic wrapper class which everyone can subclass from? >>>> >>>> bufferedStream := anyStreamClass buffered >>>> >>>> (buffered wrapper) -> (anyStreamClass) >>>> >>> >>> See above, it's just split in BufferedRead/WriteXtream >>> >>> Or see the example (a bit heavy) >>> Â tmp := ((StandardFileStream readOnlyFileNamed: (SourceFiles at: 2) name) >>> Â Â Â readXtream ascii buffered decodeWith: (UTF8TextConverter new >>> installLineEndConvention: nil)) buffered. >>> >> >> yes. its a bit heavy, but this is a way how one should build a chains >> of streams. >> Except that there should be only streams in chain, no non-stream >> converters in between :) >> >>> >>>> i don't see where else you should care of buffering explicitly in >>>> anyStreamClass. >>>> >>>> And, how you can avoid byte-by-byte conversion in utf8? It should >>>> iterate over bytes to determine the characters anyways. >>> >>> True, it is faster because you scan fast with a primitive, >>> then copy a whole chunk with replaceFrom:to:with:startingAt: primitive >>> >>> Of course, if you handle some cyrillic files, then this strategy won't >>> be efficient. It just work in ASCII dominated files. >>> UTF8 itself would not be an optimal choice for cyrillic anyway... >>> >> I prefer to use UFT8 nowadays, instead of old rubbish encodings, which >> is many :) >> >>>> But sure thing, nothing prevents you from buffering things in a way like: >>>> >>>> reader := anyStream buffered wrapWith: UTF8Reader. >>>> >>> >>> My above example is just equivalent to: >>> >>> reader := (anyStream buffered wrapWith: UTF8Reader) buffered. >>> >>> Then even if I use reader next, a whole buffer of UTF8 is converted >>> (presumably by large chunks) >>> >> >> Right, nobody says that its not possible to do double-buffering. >> First, by wrapping an original stream (presumably file-based) >> and second - an output of utf8 converter. >> >> [snip] >> >> -- >> 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 > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Feb. 27, 2010

Re: [Pharo-project] [Fwd: [squeak-dev] The Trunk: Kernel-ar.411.mcz]

by StÃ©phane Ducasse

:) http://code.google.com/p/pharo/issues/detail?id=2087 :) On Feb 27, 2010, at 8:29 AM, Miguel Enrique CobÃ¡ Martinez wrote: > Maybe we can add this to the cleanUpForRelease script. > > Cheers > -- > Miguel CobÃ¡ > http://miguel.leugim.com.mx > > From: commits(a)source.squeak.org > Date: February 26, 2010 6:38:01 PM GMT+01:00 > To: squeak-dev(a)lists.squeakfoundation.org, packages(a)lists.squeakfoundation.org > Subject: [squeak-dev] The Trunk: Kernel-ar.411.mcz > Reply-To: squeak-dev(a)lists.squeakfoundation.org > > > Andreas Raab uploaded a new version of Kernel to project The Trunk: > http://source.squeak.org/trunk/Kernel-ar.411.mcz > > ==================== Summary ==================== > > Name: Kernel-ar.411 > Author: ar > Time: 26 February 2010, 7:36:40.257 pm > UUID: b69a28db-8475-bc4b-89ed-285ccf3841cd > Ancestors: Kernel-ul.410 > > Add MethodDictionary class>>compactAllInstances to save space in releases. Compacting all MDs in my images saves 600k in image size which isn't bad at all. > > =============== Diff against Kernel-ul.410 =============== > > Item was added: > + ----- Method: MethodDictionary class>>compactAllInstances (in category 'initialization') ----- > + compactAllInstances "MethodDictionary compactAllInstances" > + "Compacts all MethodDictionaries to save space" > + > + | oldInstances newInstances | > + oldInstances := self allInstances. > + newInstances := oldInstances collect:[:md| > + (self new: md size) > + compactCopyFrom: md; > + yourself]. > + oldInstances elementsForwardIdentityTo: newInstances. > + ! > > Item was added: > + ----- Method: MethodDictionary>>compactCopyFrom: (in category 'private') ----- > + compactCopyFrom: sourceMD > + "Copy the contents of source dictionary without growing" > + > + sourceMD keysAndValuesDo:[:key :value| | index | > + index := self scanFor: key. > + (self basicAt: index) ifNotNil:[self error: 'Something is horribly broken']. > + self basicAt: index put: key. > + array at: index put: value. > + tally := tally + 1. > + ]. > + self size = self capacity ifTrue:[self grow]. "grow only if we reach capacity" > + ! > > > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Feb. 27, 2010

Re: [Pharo-project] [Fwd: [squeak-dev] The Trunk: Kernel-ar.412.mcz]

by StÃ©phane Ducasse

http://code.google.com/p/pharo/issues/detail?id=2086 If you publish a slice this will help :) Stef On Feb 27, 2010, at 8:30 AM, Miguel Enrique CobÃ¡ Martinez wrote: > This can be useful too. > > -- > Miguel CobÃ¡ > http://miguel.leugim.com.mx > > From: commits(a)source.squeak.org > Date: February 26, 2010 10:27:26 PM GMT+01:00 > To: squeak-dev(a)lists.squeakfoundation.org, packages(a)lists.squeakfoundation.org > Subject: [squeak-dev] The Trunk: Kernel-ar.412.mcz > Reply-To: squeak-dev(a)lists.squeakfoundation.org > > > Andreas Raab uploaded a new version of Kernel to project The Trunk: > http://source.squeak.org/trunk/Kernel-ar.412.mcz > > ==================== Summary ==================== > > Name: Kernel-ar.412 > Author: ar > Time: 26 February 2010, 11:26:03.981 pm > UUID: 59fae938-7c7e-714c-8299-9d6e1ae5583b > Ancestors: Kernel-ar.411 > > Introduce a cleanUp/cleanUp: protocol based on the proposal from Mantis: > > http://bugs.squeak.org/view.php?id=7244 > > The cleanUp protocol takes an optional argument to indicate whether we're doing an aggressive cleanup (which involves deleting projects, change sets, and possibly other destructive actions) or a more gentle cleanup that's only supposed to clean out transient caches. > > > =============== Diff against Kernel-ar.411 =============== > > Item was added: > + ----- Method: Behavior>>cleanUp (in category 'initialize-release') ----- > + cleanUp > + "Clean out any caches and other state that should be flushed when trying to get an image into a pristine state. Subclasses may override #cleanUp: to provide different levels of cleanliness" > + ! > > Item was added: > + ----- Method: ClassOrganizer class>>cleanUp: (in category 'class initialization') ----- > + cleanUp: aggressive > + "Remove empty method categories when cleaning aggressively" > + > + aggressive ifTrue:[Smalltalk removeEmptyMessageCategories]. > + ! > > Item was added: > + ----- Method: MethodDictionary class>>cleanUp: (in category 'initialization') ----- > + cleanUp: aggressive > + "Compact method dictionaries when aggressively cleaning up" > + > + aggressive ifTrue:[self compactAllInstances]. > + ! > > Item was added: > + ----- Method: Behavior class>>cleanUp (in category 'class initialization') ----- > + cleanUp > + "Flush the obsolete subclasses." > + > + self flushObsoleteSubclasses! > > Item was added: > + ----- Method: Behavior>>cleanUp: (in category 'initialize-release') ----- > + cleanUp: aggressive > + "Clean out any caches and other state that should be flushed when trying to get an image into a pristine state. The argument should be used to indicate how aggressive the cleanup should be. Some subclasses may act differently depending on its value - for example, ChangeSet will only delete all unused and reinitialize the current change set if we're asking it to be aggressive." > + > + ^self cleanUp! > > > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Feb. 27, 2010

Re: [Pharo-project] We should run + fix the tests in 1.1

by StÃ©phane Ducasse

On Feb 26, 2010, at 9:55 PM, Michael Roberts wrote: > my experience is similar to Yanni, in that I found a series of > updates, every so often, would break the build. it became a pain to > keep on checking and fixing things. So i am spending my time on > trying to script some sanity checks and logic for common errors. Given > the pace of updates, whilst human intervention is the simple solution, > i don't think it is great. One gets behind very quickly. > > Also, how many developers regularly look at the test result pages (the > first version on the wiki, the gforge /experimental, yanni's hudson > setup) for the core image and act on the implied bugs in the update? > i.e comment on the issue tracker related to the specific update just > published > > I think we need to email the delta of each test run to this mailing > list as soon as it is run. Yes I think that we should streamlined our process - fast running tests - faster tests -> we should have a look at the changes adrian kuhn sent - run and fix more often. Stef > > thanks, > Mike > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Feb. 27, 2010

Re: [Pharo-project] [Fwd: [squeak-dev] The Trunk: Kernel-ar.411.mcz]

by StÃ©phane Ducasse

Thanks a lot miguel Stef On Feb 27, 2010, at 8:29 AM, Miguel Enrique CobÃ¡ Martinez wrote: > Maybe we can add this to the cleanUpForRelease script. > > Cheers > -- > Miguel CobÃ¡ > http://miguel.leugim.com.mx > > From: commits(a)source.squeak.org > Date: February 26, 2010 6:38:01 PM GMT+01:00 > To: squeak-dev(a)lists.squeakfoundation.org, packages(a)lists.squeakfoundation.org > Subject: [squeak-dev] The Trunk: Kernel-ar.411.mcz > Reply-To: squeak-dev(a)lists.squeakfoundation.org > > > Andreas Raab uploaded a new version of Kernel to project The Trunk: > http://source.squeak.org/trunk/Kernel-ar.411.mcz > > ==================== Summary ==================== > > Name: Kernel-ar.411 > Author: ar > Time: 26 February 2010, 7:36:40.257 pm > UUID: b69a28db-8475-bc4b-89ed-285ccf3841cd > Ancestors: Kernel-ul.410 > > Add MethodDictionary class>>compactAllInstances to save space in releases. Compacting all MDs in my images saves 600k in image size which isn't bad at all. > > =============== Diff against Kernel-ul.410 =============== > > Item was added: > + ----- Method: MethodDictionary class>>compactAllInstances (in category 'initialization') ----- > + compactAllInstances "MethodDictionary compactAllInstances" > + "Compacts all MethodDictionaries to save space" > + > + | oldInstances newInstances | > + oldInstances := self allInstances. > + newInstances := oldInstances collect:[:md| > + (self new: md size) > + compactCopyFrom: md; > + yourself]. > + oldInstances elementsForwardIdentityTo: newInstances. > + ! > > Item was added: > + ----- Method: MethodDictionary>>compactCopyFrom: (in category 'private') ----- > + compactCopyFrom: sourceMD > + "Copy the contents of source dictionary without growing" > + > + sourceMD keysAndValuesDo:[:key :value| | index | > + index := self scanFor: key. > + (self basicAt: index) ifNotNil:[self error: 'Something is horribly broken']. > + self basicAt: index put: key. > + array at: index put: value. > + tally := tally + 1. > + ]. > + self size = self capacity ifTrue:[self grow]. "grow only if we reach capacity" > + ! > > > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Feb. 27, 2010

Re: [Pharo-project] Quasi-stateful traits?

by StÃ©phane Ducasse

On Feb 27, 2010, at 4:13 AM, Igor Stasenko wrote: > On a second thought, i think this is not really necessary. > > Traits can be reformulated to be purely a method source holders, not > holders of compiled methods. > (And btw, this is actually true, due to the latest changes in traits, > because of super sends issues and > #methodClass), we only need to push it a little further and get rid of > useless limitations. > > The point is, that all trait methods should _always_ be compiled in > the scope of the class to which it applied. Yes this was implied in what I said but I did not want to say it explictly :) > Because, for any variable name, which not declared explicitly in the > method's scope, we can't tell anything about it, > until we apply this method to the real class (See the Class>>bindingOf: ) > This means that, even if you having the trait method: > > foo > ^ Array new: 10 > > the binding of 'Array' variable may be different, depending on class > where its installed. > To check it, you can try following at home: > > Object subclass: #ZZZZ > instanceVariableNames: '' > classVariableNames: 'DD' > poolDictionaries: '' > category: 'ZZZZ' > > "add new pool variable" > ZZZZ classPool at: #Array put: 10. > > "now add the method" > array > ^ Array > > and now evaluate the following: > ZZZZ new array > > ------------- > But what makes > array > ^ Array > > method any better than > > array > ^ array := 10. > > in this regard? > > Nothing. So, why not drop the limitation, and instead of punishing > developer for use undeclared vars in trait methods, > punish him for use of undeclared variables, when he tries to apply the > trait to concrete class, where all such var names should obtain > meaning? > > Then, ultimately, what is the point in storing compiling methods in > Trait (not for classes, where it applied). We could just check the > syntax, but should not produce any CompiledMethod instances at all. > > What other problems i don't see here? I do not see. I think that this is nice to do another iteration around traits. > > > On 27 February 2010 02:10, Stan Shepherd <stan.shepherd414(a)gmail.com> wrote: >> >> >> Igor Stasenko wrote: >>> >>> One of the ways of introducing a stateful traits is changing the VM >>> object format. >>> >> Sounds like it could be very powerful. >> >> As it happens, in the fork healing example, it's the very statelessness of >> the traits that make it work so simply. By taking out the check for >> statefulness when the method is moved to a trait, the trait will quite >> happily address the several variables in its user classes. This then removes >> any need for accessors, helper classes for state, initialization, or other >> attempts to tame the beast. >> >> I wouldn't want to rely on it continuing to work in all conditions, but as a >> step in a refactoring it seems very handy. >> >> ..Stan >> -- >> View this message in context: http://n4.nabble.com/Quasi-stateful-traits-tp1571120p1571553.html >> Sent from the Pharo Smalltalk mailing list archive at Nabble.com. >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > > > > -- > 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

Feb. 27, 2010

Re: [Pharo-project] Quasi-stateful traits?

by StÃ©phane Ducasse

orthogonally to traits I sometimes would like python like hash based (but class and not object) semantics ie Object dictionaryVariable: #MyClass Igor now one of the problem is see with the possible to add and access slot everywhere is illustrated by morphic code when a method add a property extension to a morph, another tests for its value and the third one remove it. You get code that is really difficult to understand. > <key1><value1> > <key2><value2> On Feb 27, 2010, at 12:39 AM, Igor Stasenko wrote: > One of the ways of introducing a stateful traits is changing the VM > object format. > There is a bits in object's header reserved for identity hash. > Instead of putting the identify hash value there, we could use it to > indicate if given object has additional arbitrary slots following the > object contents: > > <header> > <ivar1> > ... > <ivarN> > <variableVar1> > ... > <variableVarM> > <key1><value1> > <key2><value2> > ... > <keyK><valueK> > > so, these keyN->valueN forming a dictionary of key/value pairs, which > can be accessed using new primitives #slotAt: and #sloatAt:put: > > slot allocaiton can be expressed as: > > newObject := object copyWithSlot: key value: value. > object becomeForward: newObject. > > (except that this is done by VM primitively). > > Once slots is allocated, object size is not grows anymore (so there > are no overhead) and as bonus, you getting a way to attach any > additional state to virtually any objects (except smallints) , for any > purposes. > Identity hash is become slower, but only at first hashing attempt. > (slotAt: #identityHash put: value) > But as benefit, we could use any object (or just 31 bit small integer) > for hash values, which will increase the hashing quality considerably. > So, it is a question, what will be faster, especially for large > dictionaries. > > Obviously, then traits free to use this to keep own state, without any > extra demands from classes where it installed: > > foo > ^ self slotAt: #foo > foo: value > self slotAt: #foo put: value > > Also, I think that with such extension, we might expect a considerable > speed boost for Magma OODB, which can use additional slot for marking > objects by own ids, as well as for marking object dirty, instead of > maintaining a huge and ineffective IdentityDictionaries to track the > objects state. > > -- > 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

Feb. 27, 2010

Re: [Pharo-project] Developing morphic apps with pharo - sorting wheat from chaff

by StÃ©phane Ducasse

Yes but somebody has to do it. We are quite open but time is an important factor :) The idea with the architectural changes at the event system was that we should be able to have multiple solutions without having the isMorphic/isMVC tests everywhere in the code. Stef On Feb 27, 2010, at 12:57 AM, Richard Durr wrote: > Maybe the Brazil part of Newspeak is an option? > > On Fri, Feb 26, 2010 at 4:34 PM, Marcus Denker <marcus.denker(a)inria.fr> wrote: > >> Why can't this stuff be *simple* and *beautiful*? >> >> Marcus >> > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Feb. 27, 2010

[Pharo-project] [Fwd: [squeak-dev] The Trunk: Kernel-ar.412.mcz]

by Miguel Enrique CobÃ¡ Martinez

This can be useful too. -- Miguel CobÃ¡ http://miguel.leugim.com.mx

Feb. 27, 2010

[Pharo-project] [Fwd: [squeak-dev] The Trunk: Kernel-ar.411.mcz]

by Miguel Enrique CobÃ¡ Martinez

Maybe we can add this to the cleanUpForRelease script. Cheers -- Miguel CobÃ¡ http://miguel.leugim.com.mx

Feb. 27, 2010