November 2013 - Pharo-dev - lists.pharo.org

Re: [Pharo-dev] flatCollect:

by Camillo Bruni

On 2013-11-04, at 17:46, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > Actually I am still confused about this, for example, > > Set new writeStream nextPut: 1; contents This should actually work the same way as OrderedCollection streamContents: [ :s | s nextPut: 1 ]. or Symbol streamContents: [ :s | s nextPutAll: 'abc' ] > does not work, so for which non-sequenceable collections would the #flatCollect: code work ? > I was thinking that maybe #streamContents: could be put higher up ? > If that would not be possible, why not ? > And how would the #flatCollect: code then work ? > > On 04 Nov 2013, at 17:36, Chris Cunningham <cunningham.cb(a)gmail.com> wrote: > >> On Sat, Nov 2, 2013 at 3:52 AM, Tudor Girba <tudor(a)tudorgirba.com> wrote: >> Indeed, it would be more elegant, but streamContents: is only defined in SequeanceableCollection, so it is not generic enough. >> >> So, then use the generic one where it is defined (Collection), and a more specific one that Sven suggested in SequenceableCollection. >> >> -Chris >> >> Doru >> >> >> On Sat, Nov 2, 2013 at 11:21 AM, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: >> BTW, it seems #flatten in 2.0 has become #flattened in 3.0 and that too might needs the #species >> >> Would it also not be better and more elegant to say >> >> self species streamContents: [ :stream | >> â¦ ] >> >> ? >> >> On 02 Nov 2013, at 09:50, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: >> >>> >>> On 01 Nov 2013, at 23:55, Tudor Girba <tudor(a)tudorgirba.com> wrote: >>> >>>> Hi, >>>> >>>> I see that Pharo 3.0 has a Collection>>flatCollect:. This is great as the method proved to be very valuable in the context of Moose. >>>> >>>> However, the current Pharo implementation is less ideal: >>>> >>>> Collection>>flatCollect: aBlock >>>> ^ Array streamContents: >>>> [:stream | >>>> self do: [:ea | stream nextPutAll: (aBlock value: ea)]] >>>> >>>> The Moose one is: >>>> Collection>>flatCollect: aBlock >>>> "Evaluate aBlock for each of the receiver's elements and answer the >>>> list of all resulting values flatten one level. Assumes that aBlock returns some kind >>>> of collection for each element. Equivalent to the lisp's mapcan" >>>> "original written by a. Kuhn and released under MIT" >>>> >>>> | stream | >>>> self isEmpty ifTrue: [ ^ self copy ]. >>>> stream := (self species new: 0) writeStream. >>>> self do: [ :each | stream nextPutAll: (aBlock value: each) ]. >>>> ^ stream contents >>>> >>>> The difference is in the type returned. The Pharo one always returns Array, while the Moose one returns a collection of the same species as the receiver. >>> >>> Sounds right, returning #species. >>> >>>> Does anyone have anything against the Moose implementation? >>>> >>>> Doru >>>> >>>> -- >>>> www.tudorgirba.com >>>> >>>> "Every thing has its own flow" >> >> >> >> >> >> -- >> www.tudorgirba.com >> >> "Every thing has its own flow" >> > >

Nov. 4, 2013

Re: [Pharo-dev] flatCollect:

by Sven Van Caekenberghe

Actually I am still confused about this, for example, Set new writeStream nextPut: 1; contents does not work, so for which non-sequenceable collections would the #flatCollect: code work ? I was thinking that maybe #streamContents: could be put higher up ? If that would not be possible, why not ? And how would the #flatCollect: code then work ? On 04 Nov 2013, at 17:36, Chris Cunningham <cunningham.cb(a)gmail.com> wrote: > On Sat, Nov 2, 2013 at 3:52 AM, Tudor Girba <tudor(a)tudorgirba.com> wrote: > Indeed, it would be more elegant, but streamContents: is only defined in SequeanceableCollection, so it is not generic enough. > > So, then use the generic one where it is defined (Collection), and a more specific one that Sven suggested in SequenceableCollection. > > -Chris > > Doru > > > On Sat, Nov 2, 2013 at 11:21 AM, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > BTW, it seems #flatten in 2.0 has become #flattened in 3.0 and that too might needs the #species > > Would it also not be better and more elegant to say > > self species streamContents: [ :stream | > â¦ ] > > ? > > On 02 Nov 2013, at 09:50, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > > > > > On 01 Nov 2013, at 23:55, Tudor Girba <tudor(a)tudorgirba.com> wrote: > > > >> Hi, > >> > >> I see that Pharo 3.0 has a Collection>>flatCollect:. This is great as the method proved to be very valuable in the context of Moose. > >> > >> However, the current Pharo implementation is less ideal: > >> > >> Collection>>flatCollect: aBlock > >> ^ Array streamContents: > >> [:stream | > >> self do: [:ea | stream nextPutAll: (aBlock value: ea)]] > >> > >> The Moose one is: > >> Collection>>flatCollect: aBlock > >> "Evaluate aBlock for each of the receiver's elements and answer the > >> list of all resulting values flatten one level. Assumes that aBlock returns some kind > >> of collection for each element. Equivalent to the lisp's mapcan" > >> "original written by a. Kuhn and released under MIT" > >> > >> | stream | > >> self isEmpty ifTrue: [ ^ self copy ]. > >> stream := (self species new: 0) writeStream. > >> self do: [ :each | stream nextPutAll: (aBlock value: each) ]. > >> ^ stream contents > >> > >> The difference is in the type returned. The Pharo one always returns Array, while the Moose one returns a collection of the same species as the receiver. > > > > Sounds right, returning #species. > > > >> Does anyone have anything against the Moose implementation? > >> > >> Doru > >> > >> -- > >> www.tudorgirba.com > >> > >> "Every thing has its own flow" > > > > > > -- > www.tudorgirba.com > > "Every thing has its own flow" >

Nov. 4, 2013

Re: [Pharo-dev] Github and Pharo

by Max Leske

FileSystem-Git is basically in alpha at the momentâ¦ Iâm rewriting it. On 04.11.2013, at 17:04, Goubier Thierry <thierry.goubier(a)cea.fr> wrote: > Ok, I tried a bit with FileSystem-Git, but it seems there is still a bit of work to do... > > I tried on one of my work repository, and: > - it failed trying to uft8convert a packed data file. > So I corrected the error (get the stream as binary!) and > - It failed looking for one of the commit IDs > I found the ref in a pack file; apparently, it's not looking in there... > I'm forcing a read of the pack files in there > - Yet another utf8convert error on binary data > Corrected, I got the pack files, but the index isn't telling me much. > I tried to list the objects in it... Unknown compression method error. > > There's a huge amount of code in there, it's a bit frightening. I think I'll stay with OSProcess a bit longer ;) > > Thierry > > Le 04/11/2013 14:28, Goubier Thierry a Ã©crit : >> >> >> Le 04/11/2013 14:09, David T. Lewis a Ã©crit : >>> On Mon, Nov 04, 2013 at 01:58:29PM +0100, Goubier Thierry wrote: >>>> >>>> >>>> Le 04/11/2013 12:11, kilon alios a ?crit : >>>>> yeap filetree did the trick here. However it does not allow to browse >>>>> through the git commits as gitfiletree does, the only commit available >>>>> is the last commit. >>>>> >>>>> I took a look at CommandShell and friends and they all look pretty much >>>>> very broken. For example in workspace I executed >>>>> [ CommandShellTranscript open.] and trying "ls" or "dir" it creates an >>>>> error because it add C path inside pharo subdirectories. Dont know if >>>>> this is normal behavior. >>> >>> Use "CommandShell open" rather than "CommandShellTranscript open". >>> >>> >>>> >>>> I hope someone with more knowledge than me of OSProcess under windows >>>> will have a look :) >>>> >>> OSProcess support for Windows is incomplete, so this will probably not >>> do what you need. If the OSProcess is included in the Windows VM, it will >>> let you run a Windows program, but it will not do most of the other >>> things >>> that you expect from OSProcess. >>> >>> Check http://www.squeaksource.com/ProcessWrapper.html for a possible >>> alternative. >> >> Thanks Dave; no easy solution on that, it seems. I'll have a look then >> with FileSystem-Git, this one may be a more portable solution. >> >> Windows is still a world apart from the rest :( >> >> Thierry > > -- > Thierry Goubier > CEA list > Laboratoire des Fondations des SystÃ¨mes Temps RÃ©el EmbarquÃ©s > 91191 Gif sur Yvette Cedex > France > Phone/Fax: +33 (0) 1 69 08 32 92 / 83 95 >

Nov. 4, 2013

Re: [Pharo-dev] flatCollect:

by Chris Cunningham

On Sat, Nov 2, 2013 at 3:52 AM, Tudor Girba <tudor(a)tudorgirba.com> wrote: > Indeed, it would be more elegant, but streamContents: is only defined in > SequeanceableCollection, so it is not generic enough. > > So, then use the generic one where it is defined (Collection), and a more specific one that Sven suggested in SequenceableCollection. -Chris > Doru > > > On Sat, Nov 2, 2013 at 11:21 AM, Sven Van Caekenberghe <sven(a)stfx.eu>wrote: > >> BTW, it seems #flatten in 2.0 has become #flattened in 3.0 and that too >> might needs the #species >> >> Would it also not be better and more elegant to say >> >> self species streamContents: [ :stream | >> â¦ ] >> >> ? >> >> On 02 Nov 2013, at 09:50, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: >> >> > >> > On 01 Nov 2013, at 23:55, Tudor Girba <tudor(a)tudorgirba.com> wrote: >> > >> >> Hi, >> >> >> >> I see that Pharo 3.0 has a Collection>>flatCollect:. This is great as >> the method proved to be very valuable in the context of Moose. >> >> >> >> However, the current Pharo implementation is less ideal: >> >> >> >> Collection>>flatCollect: aBlock >> >> ^ Array streamContents: >> >> [:stream | >> >> self do: [:ea | stream nextPutAll: (aBlock value: ea)]] >> >> >> >> The Moose one is: >> >> Collection>>flatCollect: aBlock >> >> "Evaluate aBlock for each of the receiver's elements and answer >> the >> >> list of all resulting values flatten one level. Assumes that >> aBlock returns some kind >> >> of collection for each element. Equivalent to the lisp's mapcan" >> >> "original written by a. Kuhn and released under MIT" >> >> >> >> | stream | >> >> self isEmpty ifTrue: [ ^ self copy ]. >> >> stream := (self species new: 0) writeStream. >> >> self do: [ :each | stream nextPutAll: (aBlock value: each) ]. >> >> ^ stream contents >> >> >> >> The difference is in the type returned. The Pharo one always returns >> Array, while the Moose one returns a collection of the same species as the >> receiver. >> > >> > Sounds right, returning #species. >> > >> >> Does anyone have anything against the Moose implementation? >> >> >> >> Doru >> >> >> >> -- >> >> www.tudorgirba.com >> >> >> >> "Every thing has its own flow" >> >> >> > > > -- > www.tudorgirba.com > > "Every thing has its own flow" >

Nov. 4, 2013

Re: [Pharo-dev] WhatsUp from: 2013-11-04 until: 2013-11-17

by Sven Van Caekenberghe

Hey Doru, On 04 Nov 2013, at 17:01, Tudor Girba <tudor(a)tudorgirba.com> wrote: > - Continue on the topic of "Pharo IDE of the Futureâ Great, looking forward to it ! FWIW, I have come around about the fonts ;-) I have been using Open Sans & Source Code Pro for a while now, and I like them. These are my font selections for my MacBook Air 13ââ (1440x900): Light and modern, like Pharo itself ! Apart from the bolding of the window title font, this code sets those fonts: SourceCodeProRegular new install. OpenSansRegular new install. FreeTypeFontProvider current updateFromSystem. #( #(#defaultFont: 'Open Sans' 12) #(#listFont: 'Open Sans' 12) #(#menuFont: 'Open Sans' 12) #(#windowTitleFont: 'Open Sans' 12) #(#balloonFont: 'Open Sans' 10) #(#codeFont: 'Source Code Pro' 11) #(#buttonFont: 'Open Sans' 12) #(#haloFont: 'Open Sans' 10)) do: [ :spec | | font | font := LogicalFont familyName: spec second pointSize: spec third. StandardFonts perform: spec first with: font ] Thanks again for taking care ! Sven

Nov. 4, 2013

Re: [Pharo-dev] Peek

by Sven Van Caekenberghe

Hi Henrik, Great writeup, thanks ! (more inline) On 04 Nov 2013, at 11:58, Henrik Johansen <henrik.s.johansen(a)veloxit.no> wrote: > On 04 Nov 2013, at 9:57 , Diego Lont <diego.lont(a)delware.nl> wrote: > >> Working on Petit Delphi we found a strange implementation for asPetitStream: >> Stream>asPetitStream >> ^ self contents asPetitStream >> >> Further investigation showed that the basic peek was not fast enough for Petit Parser, as it is used a lot. So it implemented a "improved unchecked peek": >> PPStream>peek >> "An improved version of peek, that is slightly faster than the built in version." >> ^ self atEnd ifFalse: [ collection at: position + 1 ] >> >> PPStream>uncheckedPeek >> "An unchecked version of peek that throws an error if we try to peek over the end of the stream, even faster than #peek." >> ^ collection at: position + 1 >> >> But in my knowledge a basic peek should be fast. The real problem is the peek in the underlying peek: >> PositionableStream>peek >> "Answer what would be returned if the message next were sent to the >> receiver. If the receiver is at the end, answer nil." >> >> | nextObject | >> self atEnd ifTrue: [^nil]. >> nextObject := self next. >> position := position - 1. >> ^nextObject >> >> That actually uses "self next". The least thing one should do is to cache the next object. But isn't there a primitive for peek in a file stream? Because al overriding peeks of PositionableStream have basically the same implementation: reading the next and restoring the state to before the peek (that is slow). So we would like to be able to remove PPStream without causing performance issues, as the only added method is the "improved peek". >> >> Stephan and Diego > > If you are reading from file, ZnCharacterStream should be a valid alternative. > If not, ZnBufferedReadStream on an internal collection stream also does peek caching. > > Beware with files though; itâs better to bench the overall operation for different alternatives. > F.ex, ZnCharacterStream is much faster than the standard Filestream for peek: > > cr := ZnCharacterReadStream on: 'PharoDebug.log' asFileReference readStream binary. > [cr peek] bench. '49,400,000 per second.' > cr close. > > FileStream fileNamed: 'PharoDebug.log' do: [:fs | [fs peek] bench] '535,000 per second.â > > but has different bulk reads characteristics (faster for small bulks, slower for large bulks, crossover-point at around 1k chars at once); > (The actual values are of course also dependent on encoder/file contents, those given here obtained with UTF-8 and a mostly/all ascii text file) > > [cr := ZnCharacterReadStream on: ('PharoDebug.log' asFileReference readStream binary ) readStream. > cr next: 65536; close] bench '105 per second.' '106 per second.â Well, I just realised that ZnCharacterReadStream and ZnCharacterWriteStream did not yet make use of the optimisations that I did for ZnCharacterEncoding some time ago. More specifically, they were not yet using #next:putAll:startingAt:toStream: and #readInto:startingAt:count:fromStream: which are overwritten for ZnUTF8Encoder with (super hacked) versions that assume most of the input will be ASCII (a reasonable assumption). I am still chasing a bug, but right now: [ (ZnCharacterReadStream on: ('timezones.json' asFileReference readStream binary)) next: 65536; close ] bench. "135 per second.â BEFORE "3,310 per second.â AFTER But of course the input file is ASCII, so YMMV. Iâll let you know when I commit this code. Sven > [FileStream fileNamed: 'PharoDebug.log' do: [:fs | fs next: 65536] > ] bench '176 per second.â > > If you use a StandardFilestream set to binary ( which has less overhead for binary nextâs compared to the MultiByteFileStream returned by asFileReference readStream)as the base stream instead, , the same general profile holds true, but with a crossover around 2k characters. > > TL;DR: Benchmark the alternatives. The best replacement option depends on your results. Appropriately (according to source and actual use) set up Zn-streams are probably your best bet. > > Cheers, > Henry

Nov. 4, 2013

Re: [Pharo-dev] Github and Pharo

by Goubier Thierry

Ok, I tried a bit with FileSystem-Git, but it seems there is still a bit of work to do... I tried on one of my work repository, and: - it failed trying to uft8convert a packed data file. So I corrected the error (get the stream as binary!) and - It failed looking for one of the commit IDs I found the ref in a pack file; apparently, it's not looking in there... I'm forcing a read of the pack files in there - Yet another utf8convert error on binary data Corrected, I got the pack files, but the index isn't telling me much. I tried to list the objects in it... Unknown compression method error. There's a huge amount of code in there, it's a bit frightening. I think I'll stay with OSProcess a bit longer ;) Thierry Le 04/11/2013 14:28, Goubier Thierry a Ã©crit : > > > Le 04/11/2013 14:09, David T. Lewis a Ã©crit : >> On Mon, Nov 04, 2013 at 01:58:29PM +0100, Goubier Thierry wrote: >>> >>> >>> Le 04/11/2013 12:11, kilon alios a ?crit : >>>> yeap filetree did the trick here. However it does not allow to browse >>>> through the git commits as gitfiletree does, the only commit available >>>> is the last commit. >>>> >>>> I took a look at CommandShell and friends and they all look pretty much >>>> very broken. For example in workspace I executed >>>> [ CommandShellTranscript open.] and trying "ls" or "dir" it creates an >>>> error because it add C path inside pharo subdirectories. Dont know if >>>> this is normal behavior. >> >> Use "CommandShell open" rather than "CommandShellTranscript open". >> >> >>> >>> I hope someone with more knowledge than me of OSProcess under windows >>> will have a look :) >>> >> OSProcess support for Windows is incomplete, so this will probably not >> do what you need. If the OSProcess is included in the Windows VM, it will >> let you run a Windows program, but it will not do most of the other >> things >> that you expect from OSProcess. >> >> Check http://www.squeaksource.com/ProcessWrapper.html for a possible >> alternative. > > Thanks Dave; no easy solution on that, it seems. I'll have a look then > with FileSystem-Git, this one may be a more portable solution. > > Windows is still a world apart from the rest :( > > Thierry -- Thierry Goubier CEA list Laboratoire des Fondations des SystÃ¨mes Temps RÃ©el EmbarquÃ©s 91191 Gif sur Yvette Cedex France Phone/Fax: +33 (0) 1 69 08 32 92 / 83 95

Nov. 4, 2013

Re: [Pharo-dev] WhatsUp from: 2013-11-04 until: 2013-11-17

by Tudor Girba

### Here's what I've been up to since the last WhatsUp: - Release of Moose 4.9 on top of Pharo 2.0 - Ported Moose to Pharo 3.0 - Consolidated the ideas on the topic of "Pharo IDE of the Future" ### What's next, until 2013-11-17 (*): - Continue on the topic of "Pharo IDE of the Future" Cheers, Doru -- www.tudorgirba.com "Every thing has its own flow"

Nov. 4, 2013

Re: [Pharo-dev] Problem with NativeBoost when loading Pharo from a .dmg

by Damien Cassou

On Mon, Nov 4, 2013 at 1:43 PM, Damien Cassou <damien.cassou(a)gmail.com> wrote: > when I try to run Pharo after having installed it to /Applications > from a .dmg file on MacOSX, I get the following problem: > > NativeBoost can't find symbol #CStackPointer Camillo found the problem: I was running Pharo on a stripped vm binary. This does not work. -- Damien Cassou http://damiencassou.seasidehosting.st "Success is the ability to go from one failure to another without losing enthusiasm." Winston Churchill

Nov. 4, 2013

Re: [Pharo-dev] WhatsUp from: 2013-11-04 until: 2013-11-17

by phil＠highoctane.be

### Here's what I've been up to since the last WhatsUp: - continued development of a business app (Seaside, Magritte 3, TWBS, NeoCSV, LDAP, custom components) - created an accounting and transactions package for supporting financials in the app - developed a trades tracking board service for the app - did a lot of Magritte descriptions, components, reports, custom components etc (mind bending at first, very nice afterwards) - enjoyed myself a lot w/ Pharo incredibly productive system in which writing tests first really helps in creating clear code ### What's next, until 2013-11-17 (*): - continue app development - try to fix FTP MetacelloToolBox feature - demonstrate app to investors - have a serious shot at Reef - make use of SandstoneDb + Fuel storage

Nov. 4, 2013