- Pharo-users - lists.pharo.org

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

by phil＠highoctane.be

CentOS6.9 for one. Phil On Thu, Oct 5, 2017 at 11:30 AM, Holger Freyther <holger(a)freyther.de> wrote: > > > 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

SVG Icons

by Steven R. Baker

Heya folks! I need to load SVG images (for icons) in my application. I've searched my 6.1 image for SVG, but haven't found anything. Is there a library for loading SVGs? I'd really like to get them directly into instances of Form if possible, but I'm flexible. :) Thanks! -Steven

Oct. 5, 2017

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