October 2017 - Pharo-users - lists.pharo.org

Re: [Pharo-users] Deploying on Linux with LibC version < 2.15

by Bruce O'Neel

Hi, Well, our redhat 6.9 systems have 2.12, so, that qualifies. And yes, we still have RedHat 6, and 6.9 was released only 6 months ago! Â It will finish extended support in a mind-blowing 7 more years in 2024. Redhat 5, still supported for another 3 years till 2020 has glibc 2.5. cheers bruce

Oct. 5, 2017

Re: [Pharo-users] Deploying on Linux with LibC version < 2.15

by Cyril Ferlicot

On Thu, Oct 5, 2017 at 11:30 AM, Holger Freyther <holger(a)freyther.de> wrote: > > > Which OS has such old versions of LibC? Which LSB standard does it support? > Hi, This is RedHat. I don't have the right to give more info than the fact it is a RedHat with a LibC version < 2.15. I don't know for the LSB support. I can ask but I will probably not know before the end of next week. -- Cyril Ferlicot https://ferlicot.fr http://www.synectique.eu 2 rue Jacques PrÃ©vert 01, 59650 Villeneuve d'ascq France

Oct. 5, 2017

Re: [Pharo-users] Deploying on Linux with LibC version < 2.15

by Holger Freyther

> On 4. Oct 2017, at 17:39, Cyril Ferlicot <cyril.ferlicot(a)gmail.com> wrote: > > Hi, > > I am migrating some applications from Pharo 4 to Pharo 6. The new > deployment of those applications needs to work on linux with LibC < > 2.15. With Pharo 4 there was a special VM[1]. I do not see such VM for > Pharo 6. Which OS has such old versions of LibC? Which LSB standard does it support?

Oct. 5, 2017

Re: [Pharo-users] Pharo Launcher Source

by Stephane Ducasse

Hi Steven Let us know your progress. Stef On Tue, Oct 3, 2017 at 9:57 PM, Steven R. Baker <steven(a)stevenrbaker.com> wrote: > > > On 03/10/17 21:51, Sven Van Caekenberghe wrote: >> >>> On 3 Oct 2017, at 21:30, Steven R. Baker <steven(a)stevenrbaker.com> wrote: >>> >>> Heya, >>> >>> I'm trying to build a Pharo Launcher of my own, but I can't find the >>> code. This says it's on SmalltalkHub: >>> https://github.com/pharo-project/pharo-launcher, but the link doesn't >>> show anything. >> As it says there: http://www.smalltalkhub.com/#!/~Pharo/PharoLauncher > Sigh. Apologies. I had an overzealous blocker. :( > > Thanks! > > -Steven > >>> I tried looking on CI for the build script, but I can't find the build >>> script, just build results. What I'm looking for is how to check out, >>> build, and run Pharo Launcher from scratch. Can someone help me with this? >>> >>> Thanks! >>> >>> -Steven >>> >>> >>> >> > >

Oct. 5, 2017

Re: [Pharo-users] Reading a text file line by line

by Stephane Ducasse

Yes I would like to have an action list. Stef On Thu, Oct 5, 2017 at 9:37 AM, Guillermo Polito <guillermopolito(a)gmail.com> wrote: > > > On Wed, Oct 4, 2017 at 10:12 PM, Stephane Ducasse <stepharo.self(a)gmail.com > > wrote: > >> Hi sven >> >> I wonder how we can make progress on this front. Because we should move >> on. >> I'm fed up to get all this crap of the old stream around. >> Could not we just keep positionable stream and start to get rest nice? >> > > Could we point it as a sprint task? > > >> Stef >> >> On Tue, Oct 3, 2017 at 4:22 PM, Sven Van Caekenberghe <sven(a)stfx.eu> >> wrote: >> > >> > >> >> On 3 Oct 2017, at 10:53, Guillermo Polito <guillermopolito(a)gmail.com> >> wrote: >> >> >> >> Yes, in my todo, but changing FileReference like that will break a lot >> of backwards compatibility :) >> > >> > Yes it will. >> > >> > I have said this before: the problem is that the current stream API is >> much too wide, we need to trim it to something closer to what a stream is >> (and not assume that a stream always lives on top of a collection). >> > >> > We have compassable streams now, they work well. But they cannot >> implement the full API (since they are not streaming over collections). The >> biggest issue are the positioning message (like #skip: and #position:) >> which assume you known where you are and can move around at will, which is >> not possible for a real, indefinite stream. >> > >> >> On Mon, Oct 2, 2017 at 10:22 AM, Stephane Ducasse < >> stepharo.self(a)gmail.com> wrote: >> >> Yes this is why we should continue to clean and remove cruft. Now I >> >> remember that guille did that for File. >> >> >> >> Stef >> >> >> >> On Mon, Oct 2, 2017 at 3:20 PM, Sven Van Caekenberghe <sven(a)stfx.eu> >> wrote: >> >> > If you do >> >> > >> >> > (File named: '/tmp/lines.txt') readStream[Do:] >> >> > >> >> > you seem to get a binary stream (this is the new implementation I >> guess), when you go via FileReference you get a character stream (but that >> are old ones). >> >> > >> >> > I know, very confusing. We're always in the midst of transitions. >> >> > >> >> >> On 2 Oct 2017, at 15:17, Stephane Ducasse <stepharo.self(a)gmail.com> >> wrote: >> >> >> >> >> >> Sven I do not see the binary stream. Is it ZnCharacterReadStream? >> >> >> >> >> >> Stef >> >> >> >> >> >> On Mon, Oct 2, 2017 at 1:22 PM, Sven Van Caekenberghe <sven(a)stfx.eu> >> wrote: >> >> >>> Hi, >> >> >>> >> >> >>>> On 2 Oct 2017, at 13:07, Dirk Olmes <dirk(a)xanthippe.ping.de> >> wrote: >> >> >>>> >> >> >>>> Hi, >> >> >>>> >> >> >>>> I'm trying to get started with Pharo doing something really >> simple - at >> >> >>>> least that's what I thought ... I'm trying to read a text file >> line by line. >> >> >>>> >> >> >>>> If I use File named: '/tmp/linex.txt' readStream nextLine I'll >> get a >> >> >>>> debugger telling me that BinaryFileStream does not understand >> nextLine. >> >> >>>> >> >> >>>> Now I've tried my best to find a stream that may be reading plain >> text >> >> >>>> lines but to no avail ... >> >> >>>> >> >> >>>> Help! >> >> >>>> >> >> >>>> -dirk >> >> >>> >> >> >>> $ cat > /tmp/lines.txt >> >> >>> one >> >> >>> two >> >> >>> three >> >> >>> >> >> >>> (FileLocator temp / 'lines.txt') contents lines. >> >> >>> >> >> >>> '/tmp/lines.txt' asFileReference contents lines. >> >> >>> >> >> >>> '/tmp/lines.txt' asFileReference readStreamDo: [ :in | >> >> >>> Array streamContents: [ :out | >> >> >>> [ in atEnd ] whileFalse: [ out nextPut: in nextLine ] ] ]. >> >> >>> >> >> >>> (File named: '/tmp/lines.txt') readStreamDo: [ :in | >> >> >>> | characterStream | >> >> >>> characterStream := ZnCharacterReadStream on: in. >> >> >>> Array streamContents: [ :out | >> >> >>> [ characterStream atEnd ] whileFalse: [ out nextPut: >> characterStream nextLine ] ] ]. >> >> >>> >> >> >>> They all return #('one' 'two' 'three'). >> >> >>> >> >> >>> In the last, more complex example, you first get a binary stream >> (and a 'line' is a character based concept), so wrapping the binary stream >> in a character read stream (which does know about lines) solves the problem. >> >> >>> >> >> >>> HTH, >> >> >>> >> >> >>> Sven >> >> >> >> >> > >> >> > >> >> >> >> >> >> >> >> >> >> -- >> >> >> >> Guille Polito >> >> Research Engineer >> >> >> >> Centre de Recherche en Informatique, Signal et Automatique de Lille >> >> CRIStAL - UMR 9189 >> >> French National Center for Scientific Research - http://www.cnrs.fr >> >> >> >> Web: http://guillep.github.io >> >> Phone: +33 06 52 70 66 13 >> > >> > >> >> > > > -- > > > > Guille Polito > > Research Engineer > > Centre de Recherche en Informatique, Signal et Automatique de Lille > > CRIStAL - UMR 9189 > > French National Center for Scientific Research - *http://www.cnrs.fr > <http://www.cnrs.fr>* > > > *Web:* *http://guillep.github.io* <http://guillep.github.io> > > *Phone: *+33 06 52 70 66 13 <+33%206%2052%2070%2066%2013> >

Oct. 5, 2017

Re: [Pharo-users] [Demo] Creating Bloc widgets: A Color Panel

by Stephane Ducasse

Thanks Stefan do you have a repo? I will take a look tomorrow since I take some vacation. Stef On Mon, Oct 2, 2017 at 4:27 PM, Stephan Eggermont <stephan(a)stack.nl> wrote: > Bloc is ready for your experiments. Here is my second one. > Please let me know what and how to improve. > > Bloc allows for the easy creation of beautiful widgets. > Here is a simple color panel that allows custom colors to be added (using > the current Morphic color selector dialog) and allows colors to be applied > using drag-and-drop. > > https://vimeo.com/236419682 > > Stephan

Oct. 5, 2017

Re: [Pharo-users] Reading a text file line by line

by Guillermo Polito

On Wed, Oct 4, 2017 at 10:12 PM, Stephane Ducasse <stepharo.self(a)gmail.com> wrote: > Hi sven > > I wonder how we can make progress on this front. Because we should move on. > I'm fed up to get all this crap of the old stream around. > Could not we just keep positionable stream and start to get rest nice? > Could we point it as a sprint task? > Stef > > On Tue, Oct 3, 2017 at 4:22 PM, Sven Van Caekenberghe <sven(a)stfx.eu> > wrote: > > > > > >> On 3 Oct 2017, at 10:53, Guillermo Polito <guillermopolito(a)gmail.com> > wrote: > >> > >> Yes, in my todo, but changing FileReference like that will break a lot > of backwards compatibility :) > > > > Yes it will. > > > > I have said this before: the problem is that the current stream API is > much too wide, we need to trim it to something closer to what a stream is > (and not assume that a stream always lives on top of a collection). > > > > We have compassable streams now, they work well. But they cannot > implement the full API (since they are not streaming over collections). The > biggest issue are the positioning message (like #skip: and #position:) > which assume you known where you are and can move around at will, which is > not possible for a real, indefinite stream. > > > >> On Mon, Oct 2, 2017 at 10:22 AM, Stephane Ducasse < > stepharo.self(a)gmail.com> wrote: > >> Yes this is why we should continue to clean and remove cruft. Now I > >> remember that guille did that for File. > >> > >> Stef > >> > >> On Mon, Oct 2, 2017 at 3:20 PM, Sven Van Caekenberghe <sven(a)stfx.eu> > wrote: > >> > If you do > >> > > >> > (File named: '/tmp/lines.txt') readStream[Do:] > >> > > >> > you seem to get a binary stream (this is the new implementation I > guess), when you go via FileReference you get a character stream (but that > are old ones). > >> > > >> > I know, very confusing. We're always in the midst of transitions. > >> > > >> >> On 2 Oct 2017, at 15:17, Stephane Ducasse <stepharo.self(a)gmail.com> > wrote: > >> >> > >> >> Sven I do not see the binary stream. Is it ZnCharacterReadStream? > >> >> > >> >> Stef > >> >> > >> >> On Mon, Oct 2, 2017 at 1:22 PM, Sven Van Caekenberghe <sven(a)stfx.eu> > wrote: > >> >>> Hi, > >> >>> > >> >>>> On 2 Oct 2017, at 13:07, Dirk Olmes <dirk(a)xanthippe.ping.de> > wrote: > >> >>>> > >> >>>> Hi, > >> >>>> > >> >>>> I'm trying to get started with Pharo doing something really simple > - at > >> >>>> least that's what I thought ... I'm trying to read a text file > line by line. > >> >>>> > >> >>>> If I use File named: '/tmp/linex.txt' readStream nextLine I'll > get a > >> >>>> debugger telling me that BinaryFileStream does not understand > nextLine. > >> >>>> > >> >>>> Now I've tried my best to find a stream that may be reading plain > text > >> >>>> lines but to no avail ... > >> >>>> > >> >>>> Help! > >> >>>> > >> >>>> -dirk > >> >>> > >> >>> $ cat > /tmp/lines.txt > >> >>> one > >> >>> two > >> >>> three > >> >>> > >> >>> (FileLocator temp / 'lines.txt') contents lines. > >> >>> > >> >>> '/tmp/lines.txt' asFileReference contents lines. > >> >>> > >> >>> '/tmp/lines.txt' asFileReference readStreamDo: [ :in | > >> >>> Array streamContents: [ :out | > >> >>> [ in atEnd ] whileFalse: [ out nextPut: in nextLine ] ] ]. > >> >>> > >> >>> (File named: '/tmp/lines.txt') readStreamDo: [ :in | > >> >>> | characterStream | > >> >>> characterStream := ZnCharacterReadStream on: in. > >> >>> Array streamContents: [ :out | > >> >>> [ characterStream atEnd ] whileFalse: [ out nextPut: > characterStream nextLine ] ] ]. > >> >>> > >> >>> They all return #('one' 'two' 'three'). > >> >>> > >> >>> In the last, more complex example, you first get a binary stream > (and a 'line' is a character based concept), so wrapping the binary stream > in a character read stream (which does know about lines) solves the problem. > >> >>> > >> >>> HTH, > >> >>> > >> >>> Sven > >> >> > >> > > >> > > >> > >> > >> > >> > >> -- > >> > >> Guille Polito > >> Research Engineer > >> > >> Centre de Recherche en Informatique, Signal et Automatique de Lille > >> CRIStAL - UMR 9189 > >> French National Center for Scientific Research - http://www.cnrs.fr > >> > >> Web: http://guillep.github.io > >> Phone: +33 06 52 70 66 13 > > > > > > -- Guille Polito Research Engineer Centre de Recherche en Informatique, Signal et Automatique de Lille CRIStAL - UMR 9189 French National Center for Scientific Research - *http://www.cnrs.fr <http://www.cnrs.fr>* *Web:* *http://guillep.github.io* <http://guillep.github.io> *Phone: *+33 06 52 70 66 13

Oct. 5, 2017

Re: [Pharo-users] Open Sourcing the Data Journalism Handbook with Grafoscopio

by Offray Vladimir Luna CÃ¡rdenas

Upps... I copied and pasted parts of my original post in the Open Knowedge Forum, so it seems that it got scrambled with some extra information from there here. Anyway I hope the message is clear. Cheers, Offray On 04/10/17 21:09, Offray Vladimir Luna CÃ¡rdenas wrote: > > Hi, > > Recently, in our local hackerspace <http://hackbo.co/>, we used, > extended and adapted, Grafoscopio > <http://mutabit.com/grafoscopio/index.en.html> to recreate the first > open source version of the Data Journalism Handbook > <http://datajournalismhandbook.org/>, in Spanish. Quoting from the > project page: > > There are some interesting Free Cultural Works > <http://freedomdefined.org/Definition> which are not open sourced. > This means that, they are covered under pretty liberal licenses, > allowing their remix, sale and modification, but the infrastructures > which support the creation, modification and publishing of such works, > donât allow wide participation and deep traceability of their > history of > such collective endeavors. > > This is our approach about alternative ways for creating such works, > addressing the above problem, using the Data Journalism Handbook as an > example (English <http://datajournalismhandbook.org/>, Spanish > <http://interactivos.lanacion.com.ar/manual-data/>) and /pocket > infrastructures/, which are simple, self > > contained, and work well on-line and off-line, like Fossil > <http://fossil-scm.org/> and > Grafoscopio <http://mutabit.com/grafoscopio/index.en.html>. Also > we extended and adapted Grafoscopio, during this project, > to make the tool suit the problem (and not the usual other way > around). > > More information and downloadable files in the project source code > repository: > > http://mutabit.com/repos.fossil/mapeda/ > > This is also an example of the kind of books you can create now > with/inside Grafoscopio (with Pandoc). > > And, of course, the customary screenshots: > > photo532578960227822324 > > photo5082366090373343168 > > Captura de pantalla del manual en Grafoscopio. > > > Cheers, > > Offray > >

Oct. 5, 2017

Open Sourcing the Data Journalism Handbook with Grafoscopio

by Offray Vladimir Luna CÃ¡rdenas

Hi, Recently, in our local hackerspace <http://hackbo.co/>, we used, extended and adapted, Grafoscopio <http://mutabit.com/grafoscopio/index.en.html> to recreate the first open source version of the Data Journalism Handbook <http://datajournalismhandbook.org/>, in Spanish. Quoting from the project page: There are some interesting Free Cultural Works <http://freedomdefined.org/Definition> which are not open sourced. This means that, they are covered under pretty liberal licenses, allowing their remix, sale and modification, but the infrastructures which support the creation, modification and publishing of such works, donât allow wide participation and deep traceability of their history of such collective endeavors. This is our approach about alternative ways for creating such works, addressing the above problem, using the Data Journalism Handbook as an example (English <http://datajournalismhandbook.org/>, Spanish <http://interactivos.lanacion.com.ar/manual-data/>) and /pocket infrastructures/, which are simple, self contained, and work well on-line and off-line, like Fossil <http://fossil-scm.org/> and Grafoscopio <http://mutabit.com/grafoscopio/index.en.html>. Also we extended and adapted Grafoscopio, during this project, to make the tool suit the problem (and not the usual other way around). More information and downloadable files in the project source code repository: http://mutabit.com/repos.fossil/mapeda/ This is also an example of the kind of books you can create now with/inside Grafoscopio (with Pandoc). And, of course, the customary screenshots: photo532578960227822324 photo5082366090373343168 Captura de pantalla del manual en Grafoscopio. Cheers, Offray

Oct. 5, 2017

Re: [Pharo-users] Behold Pharo: The Modern Smalltalk

by Offray Vladimir Luna CÃ¡rdenas

What I like most about this article is the comparisons with common trends (Pharo is to Smalltalk like Clojure is to Lisp) that bridge the gap between audiences. I would add some link to Cuis Smalltalk in the mention of the Smalltalk families, because of its minimalist approach. Also, may be you can add some mention to Grafoscopio [1] to complement the link about medicine data visualization. That link is getting old, but Grafoscopio community is moving and making other new project on data activism, visualization and storytelling, with more links to deep in (and upcoming news soon). [1] http://mutabit.com/grafoscopio/index.en.html Thanks, Offray On 04/10/17 05:30, horrido wrote: > Behold Pharo: The Modern Smalltalk > <https://medium.com/smalltalk-talk/behold-pharo-the-modern-smalltalk-38e132c…> > > If you would like to suggest some edits, I'm all ears. Anything to improve > the impact of the article. > > Thanks. > > > > -- > Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html > >

Oct. 5, 2017