January 2014 - Pharo-dev - lists.pharo.org

Re: [Pharo-dev] bugs with blocks

by Camille Teruel

So with apparently removing the fifth line of MethodContext>>#sourceNode solves the problem, i.e by replacing: sourceNode | activePC | activePC := pc ifNil: [ self startpc + 1] ifNotNil: [pc - 1]. activePC <= self startpc ifTrue: [ activePC := pc ]. ^(method sourceNodeForPC: activePC) methodOrBlockNode with: sourceNode | activePC | activePC := pc ifNil: [ self startpc + 1] ifNotNil: [pc - 1]. ^(method sourceNodeForPC: activePC) methodOrBlockNode But I don't know of its correct, need an expert review :) On 26 janv. 2014, at 10:07, Camille Teruel <camille.teruel(a)gmail.com> wrote: > [ [ ] ] > prints: > [ ] > instead of: > [ [ ] ] > > and > [ :arg | [ arg ] ] > prints: > DoIt > ^ [ :arg | [ arg ] ] yourself > instead of: > [ :arg | [ arg ] ] > > > Apparently it's the print that is not correct because of problem in #sourceNode. > Any clue? Marcus? ClÃ©ment?

Jan. 26, 2014

bugs with blocks

by Camille Teruel

[ [ ] ] prints: [ ] instead of: [ [ ] ] and [ :arg | [ arg ] ] prints: DoIt ^ [ :arg | [ arg ] ] yourself instead of: [ :arg | [ arg ] ] Apparently it's the print that is not correct because of problem in #sourceNode. Any clue? Marcus? ClÃ©ment?

Jan. 26, 2014

Re: [Pharo-dev] Pharo 3.0 on Raspberry Pi - Yes/No

by Pharo4Stef

Thanks for this update!!! Keep pushing Stef On 23 Jan 2014, at 17:04, Jean Baptiste Arnaud <jbaptiste.arnaud(a)gmail.com> wrote: > I made some advance and cleaning about the RaspberryPi, compilation. > I cross compile from an unix slave, that is really faster and allow me easily to compile the fast bltbit file. > > Now I integrate the fastbltbit into the StackVM (there a job associated but at term It will be merged): > https://ci.inria.fr/pharo-contribution/view/RaspberryPi/job/RaspberryPi-Cro… > https://ci.inria.fr/pharo-contribution/view/RaspberryPi/job/RaspberryPi-Cro… > We have a small bug on the git tracker now but once it will solve the job will automatically follow the update. > The version downloadable should work. > > I try Sven you are right the UI seems always busy even with fast bltbit (at least on my RaspberryPi ). > I will inspect that. > If you have already clues about that, feel free to educate me :-). > > > On 20 Jan 2014, at 23:56, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > >> Hi Jean Baptiste, >> >> On 20 Jan 2014, at 21:51, Jean Baptiste Arnaud <jbaptiste.arnaud(a)gmail.com> wrote: >> >>> >>> On 20 Jan 2014, at 19:32, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: >>> >>>> Hi, >>>> >>>> Here is another step forward in getting Pharo 3.0 to run on a Raspberry Pi. >>>> >>>> Yes: >>>> >>>> pi@raspberrypi ~/Pharo-3.0 $ ../PharoRPi/PharoS -vm-display-null -vm-sound-null Pharo.image eval 'SystemVersion current' >>>> Pharo3.0 of 18 March 2013 update 30710 >>>> >>>> pi@raspberrypi ~/Pharo-3.0 $ ../PharoRPi/PharoS -vm-display-null -vm-sound-null Pharo.image eval 'ZTimestamp now' >>>> 2014-01-20T18:21:50Z >>>> >>>> No errors. >>>> >>>> >>>> No: >>>> >>>> When doing something more complex, like: >>>> >>>> pi@raspberrypi ~/Pharo-3.0 $ ../PharoRPi/PharoS -vm-display-null -vm-sound-null Pharo.image eval --no-quit 'ZnServer startDefaultOn: 1701' >>>> a ZnManagingMultiThreadedServer(running 1701) >>>> >>>> The HTTP Server does respond normally to one request and then seems to hang. >>> Strange ... >> >> Yeah, I will retest tomorrow or so, the wireless adaptor on the Pi did act a bit up during testing, maybe that interfered, I don't know. >> >>>> When running with a UI, the image comes up, draws everything but remains unresponsive otherwise. >>> I think it is because the UI is to slow and run in software only. >>> The raspberry completely overcharged by the ui. >>> I actually push fast bltbit, then we should have a slow but responsible UI . >> >> Hmm, it really didn't do anything, I try again. >> >>>> No PharoDebug.log output. >>> Because that do not crash just over lag. Due to the UI. >> >> I just meant to say there were no errors ;-) >> >> Sending USR1 didn't reveal much either (no weird loops). >> >> I still think there is something wrong, does it work for you ? >> >> Sven >> >>>> Events ? Multi-processing ? >>>> >>>> >>>> How ? >>>> >>>> Use Jean-Baptiste's VM from here: >>>> >>>> https://ci.inria.fr/pharo-contribution/view/RaspberryPi/job/RaspberryPi-Com… >>>> >>>> Take a stock 3.0 image and apply Pavel's unloadNB.st script (see the thread with subject unload all). >>>> >>>> So, we're getting closer... >>>> >>>> If anyone is interested, I could make some kind of all in one download. >>>> >>>> Sven >>>> >>>> >>> >>> Best Regards >>> Jean Baptiste Arnaud >>> jbaptiste.arnaud(a)gmail.com >>> >>> >>> >>> >>> >>> >>> >> >> > > Best Regards > Jean Baptiste Arnaud > jbaptiste.arnaud(a)gmail.com > > > > > > >

Jan. 26, 2014

Re: [Pharo-dev] About doing things late (1 month before release)

by Pharo4Stef

+ 1000 > We should be restrained at the start of Pharo 4 development too because we firstly need to improve modularization of the system. It's common that at the start of the development cycle a huge amount of various modifications is integrated and often with only little regards on modularization. Then to improve the Pharo in this frontline is very hard and ungrateful task. > At the start of the new release we firstly need to change our system and integration tools to take this into account... > > Cheers, > -- Pavel

Jan. 26, 2014

Pharoers in San Francisco

by Pharo4Stef

Hi guys I will visit San francisco and I was wondering if some of you are living there. Because we could meet. Stef

Jan. 26, 2014

Re: [Pharo-dev] how do I install gitfiletree?

by Eliot Miranda

On Sat, Jan 25, 2014 at 1:05 AM, GOUBIER Thierry <thierry.goubier(a)cea.fr>wrote: > Yes! Would that mean a working OSProcess for Windows wouldn't be far, > then? > That's right. Any volunteers to take the code and port it? I haven't got cycles to spare doing this myself. > > Thierry > > ------------------------------ > *De :* Pharo-dev [pharo-dev-bounces(a)lists.pharo.org] de la part de Eliot > Miranda [eliot.miranda(a)gmail.com] > *Date d'envoi :* vendredi 24 janvier 2014 19:08 > *Ã :* Pharo Development List > *Objet :* Re: [Pharo-dev] how do I install gitfiletree? > > > > > On Thu, Jan 23, 2014 at 1:57 AM, Esteban Lorenzano <estebanlm(a)gmail.com>wrote: > >> >> On 23 Jan 2014, at 10:50, phil(a)highoctane.be wrote: >> >> I had a talk with Thierry and GitFileTree isn't supported on Windows. >> >> Due to OSProcess. >> >> Is the libgit2 going to solve that? >> >> >> yes, libgit2 will be distributed withâ¦ erâ¦ wellâ¦ pharo 4 :) >> (if my experiments works, and I finish in time, and, and, and... :) >> >> alsoâ¦ we need to make OSProcess work in windows tooâ¦ >> > > I already did back in 2007 for Cadence. You'll see the > Win32OSProcessPlugin in the Cog plugins. > -- > best, > Eliot > -- best, Eliot

Jan. 26, 2014

Re: [Pharo-dev] Bad naming: users

by Sebastian Sastre

sure. Iâm okay with traits. Itâs kind of cool to have them. It just happens Iâve never needed them. The thing is about the names and too common and generic names high in the hierarchy is not so great. Is not a terrible thing either, just not great. Object>>name comes to mind On Jan 25, 2014, at 7:49 PM, Pharo4Stef <pharo4Stef(a)free.fr> wrote: > sebastian > > Doing is difficult. Do you think that we did not reimplemented traits from scratch already once. > May be we are just not smart enough or may be the problem is more complex that people think it is. > You can ask around me. Iâm not happy with traits but Iâm not happy with single inheritance too and I do > not like multiple inheritance either. So :) > > I can tell you tales on huge macros in lisp that generate pages of macros and a company wanted to hire > me to add concepts in the language to remove these hug macros. > > the grass is always greener elsewhere, no? > > If we want to really improve the system we should accept that it may not be a simple easy path. > > Stef > > > On 21 Jan 2014, at 19:07, Sebastian Sastre <sebastian(a)flowingconcept.com> wrote: > >> We have to be careful about this. >> >> Iâm not saying traits doesnât have its place but they are a solution to millions of non-problems >> >> Here is a post to reflect and learn from the problems of our neighbours, the lispers guys: >> Lisp: more is less >> >> http://jameso.be/2014/01/19/lisp.html >> >> It would be super awesome if we never ever ever have those problems >> >> >> >> >> >> >> >> On Jan 21, 2014, at 3:41 PM, Esteban A. Maringolo <emaringolo(a)gmail.com> wrote: >> >>> This is where the "only 5 reserved keywords" stop being true :) >>> >>> I've been bitten by similar things and ended up using my own selectors, sometimes with a prefix. >>> >>> Regards! >>> >>> Esteban A. Maringolo >>> >>> >>> 2014/1/21 Camille Teruel <camille.teruel(a)gmail.com> >>> >>> On 21 janv. 2014, at 17:53, Stephan Eggermont <stephan(a)stack.nl> wrote: >>> >>>> I tried loading Deltawerken in Pharo 3.0 and noticed >>>> it is now impossible to load code where a class side method is defined named users. >>>> >>>> DEUser class>>users >>>> ^self subclassResponsibility >>>> >>>> Stephan >>> >>> I guess it's a consequence of the unification of Class and Trait APIs. Now SomeClass users must answer an empty collection. >>> So you experience a name clash between Pharo meta-level and your domain :( >>> I still think it was a mistake too push that unification that far, i.e having classes responding to trait specific methods and vice-versa. >>> >>> >> >

Jan. 25, 2014

Re: [Pharo-dev] browsing comment versions

by Nicolai Hess

2014-01-25 Pharo4Stef <pharo4Stef(a)free.fr> > What I would love is to find the bug that blocks me to edit comment :) > > On 22 Jan 2014, at 22:51, Nicolai Hess <nicolaihess(a)web.de> wrote: > > > Hi, > > > > someone interested in browsing older versions of class comments again? > > The ClassCommentVersionBrowser is gone, but I can add it > > to the NewVersionBrowser. Just some additional changes to class > > ChangeSet and NewVersionBrowser are needed. > > > > What do you think? > > > > > > nicolai > > > > Where is a bug?

Jan. 25, 2014

Re: [Pharo-dev] 12259: FileSystem memory reads writesusing a binary stream by default

by Max Leske

So in favor of not modifying ReadStream I implemented your suggestion #binaryReadStream in Filesystem (will not work on all streams now but thatâs ok for me until we get Xstreams). Please take a look and let me know what you think (ReadStream would have been 2 methods only vs. ~6 :) ). Name: SLICE-Issue-12259-FileSystem-memory-readswrites-using-a-binary-stream-by-default-MaxLeske.1 Author: MaxLeske Time: 25 January 2014, 11:38:48.027093 pm UUID: 1248d0f9-f094-400f-a736-23fd41d12e50 Ancestors: Dependencies: FileSystem-Tests-Core-MaxLeske.67, FileSystem-Memory-MaxLeske.46, FileSystem-Disk-MaxLeske.72, FileSystem-Core-MaxLeske.139 * added #binaryReadStream and friends to FileSystem (for compatibility) Cheers, Max On 10.12.2013, at 22:19, Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com> wrote: > The more you add, the more you'll have to remove > > > 2013/12/10 Damien Cassou <damien.cassou(a)gmail.com> > > On Dec 5, 2013 10:50 PM, "Max Leske" <maxleske(a)gmail.com> wrote: > > > > There are several different approaches in different places: > > > > - FileStream reads strings by default. #binary and #ascii switch between formats. File streams use an internal buffer which is either a String (default) or a ByteArray. Itâs even possible to switch between binary and ascii midstream without losing information (if done right) because it only affects the buffer. > > - ReadStream and WriteStream cannot change their format. Their behavior is determined by the underlying collection. Forcing conversions (e.g. by #asString) can lead to loss of information > > - RWBinaryOrTextStream (and other subclasses of ReadWriteStream) also support the #binary #ascii method of switching format. Default is #ascii > > - SocketStream uses the same #binary / #ascii mechanism. Default is #ascii > > - ZnLimitedReadStream uses the same #binary / #ascii mechanism. Default is #binary (implicit); depends on the underlying stream > > > > I think the pattern to follow is clear: ReadStream and WriteStream should allow switching format with #ascii and #binary, default should be #ascii. However, I suspect thereâs a reason that these classes donât support switching, namely that switching makes the implementation more complicated and also slower because more checks need to be made. > > > > The easiest solution I see would be to implement something like this: > > > > ReadStream>>next > > ^ self isBinary > > ifTrue: [ self basicNext asCharacter ] > > ifFalse: [ self basicNext ] > > > > However, #next et al. are implemented in a plugin and the primitive method looks like this: > > > > ReadStream>>next > > <primitive: 65> > > position >= readLimit > > ifTrue: [^nil] > > ifFalse: [^collection at: (position := position + 1)] > > > > This means the collection instance variable has to hold either a binary or a string collection. > > > > Iâve found a solution which would work and Iâve whipped up a working way (thereâs space for improvementâ¦): > > > > ReadStream>>binary > > collection isString ifFalse: [ ^ self ]. > > collection := (ByteArray new: collection size) copyReplaceFrom: 1 to: collection size with: collection > > > > ReadStrem>>ascii > > collection isString ifTrue: [ ^ self ]. > > collection := (String new: collection size) copyReplaceFrom: 1 to: collection size with: collection > > > > @Damien > > opposed to what I wrote earlier, #asString does *not* destroy non-printable characters. Instead, every byte (from 0 to 255) is encoded as a character and thus the string can be converted back to a ByteArray *without* loss of information. Sorry about that. > Thank you very much for your analysis. I'm a bit reluctant to change ReadStream now, but I could be ok with enough unit tests. > Another potential solution: What about adding a #binaryReadStream method to the memory file system as a workaround before the introduction of xstreams ? > > > With this change in place the 12259 would become obsolete. > > > > Please let me know what you think. This is a pretty big change that might have a lot of consequences in the image. > > > > Cheers, > > Max > > > > On 04.12.2013, at 13:14, Max Leske <maxleske(a)gmail.com> wrote: > > > >> Let me see what I can come up with. > >> > >> > >> On 03.12.2013, at 19:36, Damien Cassou <damien.cassou(a)gmail.com> wrote: > >> > >>> Thanks Max for the report. Do you have an idea on how we could solve the problem ? The previous behaviour was not acceptable either because the streams that came out of a memory filesystem were the only ones with binary content > >>> > >>> On Dec 3, 2013 5:35 PM, "Max Leske" <maxleske(a)gmail.com> wrote: > >>>> > >>>> Damien, Marcus > >>>> > >>>> this change breaks a lot of things in FileSystem-Git. I donât disagree with the idea that reading characters should be default (one could argue about itâ¦) but your change makes it IMPOSSIBLE to read bytes because unprintable characters are discarded! So if my ByteArray is a NULL terminated string, for instance, I can not check for the NULL termination anymore. > >>>> > >>>> Cheers, > >>>> Max > >> > >> > > >

Jan. 25, 2014

fun with update:

by Pharo4Stef

During my analysis of update: methods (I started to extract conditional leaves : simple refactoring no change) and I found the following We are lucky because this is SimpleHierarchicalListMorph and I prefer not to think about ComplexHierarchicalListâ¦ update: aSymbol aSymbol == getSelectionSelector ifTrue: [self selection: self getCurrentSelectionItem. ^self]. aSymbol == getListSelector ifTrue: [self list: self getList. ^self]. ((aSymbol isKindOf: Array) and: [aSymbol size > 1 and: [aSymbol first == getListSelector and: [ aSymbol second == #openPath]]]) "allow directed path opening where multiple trees exist" ifTrue: [^(scroller submorphs at: 1 ifAbsent: [^self]) openPath: (aSymbol allButFirst: 2)]. ((aSymbol isKindOf: Array) and: [aSymbol size > 1 and: [aSymbol first == getListSelector and: [ aSymbol second == #openItemPath]]]) "allow directed path opening where multiple trees exist" ifTrue: [^(scroller submorphs at: 1 ifAbsent: [^self]) openItemPath: (aSymbol allButFirst: 2)]. ((aSymbol isKindOf: Array) and: [aSymbol notEmpty and: [aSymbol first == #openPath]]) ifTrue: [^(scroller submorphs at: 1 ifAbsent: [^self]) openPath: aSymbol allButFirst]. ((aSymbol isKindOf: Array) and: [aSymbol size = 2 and: [aSymbol first = getListSelector and: [ aSymbol second == #expandRoots]]]) ifTrue: [^self expandRoots]. ((aSymbol isKindOf: Array) and: [aSymbol notEmpty and: [aSymbol first = getListSelector and: [ aSymbol second == #expandAll]]]) ifTrue: [^self expandAll]

Jan. 25, 2014