January 2016 - Pharo-users - lists.pharo.org

Re: [Pharo-users] [Moose-dev] Specific Domain Visualizations: a glimpse of medicine public data released by governments

by Offray Vladimir Luna CÃ¡rdenas

Updated, including Ben's suggestions and a last version of data visualizations. Here is the link: http://mutabit.com/offray/blog/en/entry/sdv-infomed Cheers, Offray On 21/01/16 11:04, Offray Vladimir Luna CÃ¡rdenas wrote: > Hi, > > As I told you before, I have been using Pharo/Moose/Roassal to > approach certain problems by agile prototyping and visualization. It > has been a really empowering community and technology and even a > newbie can feel more eloquent talking to/with computers, so thanks as > always. > > Here is the blog post with more details: > > http://mutabit.com/offray/blog/en/entry/sdv-infomed > > And here the tweet if you're in that network and want to reshare: > > https://twitter.com/offrayLC/status/689854446541611008 > > Hopefully I have been clear in the blog, but any advice to my almost > self taught English, or proof reading or improvements are welcomed. I > also hope putting proper credits to all the people involved in this > visualization. And hopefully soon (at some point in February) I will > be sharing some advances in the interactive notebook front also. > > Cheers, > > Offray > _______________________________________________ > Moose-dev mailing list > Moose-dev(a)list.inf.unibe.ch > https://www.list.inf.unibe.ch/listinfo/moose-dev >

Jan. 23, 2016

Re: [Pharo-users] Ready to play guinea pig for UI improvements

by Werner Kassens

> On 01/22/2016 01:31 PM, Nicolai Hess wrote: >> I think this is a problem of the way nautilus adds a breakpoint for >> debugging the test. >> (source code and byte code aren't in sync). opened bug report 17455 werner

Jan. 22, 2016

Re: [Pharo-users] Dynamic Typing > Static Typing? Â« games.greggman.com

by Thierry Goubier

Le 22/01/2016 19:35, stepharo a Ã©crit : > >> - Performance: for a compiler, having access to static types makes >> compiling and performance optimisation a lot easier. This is my >> current project (R compilation to heterogeneous targets) and I find >> that type inference over R code is a hard (and interesting) subject. > > Thierry you see what I would love to have is a R to Pharo :) You have I think a lot of the pieces already... SciSmalltalk and Roassal. But I wouldn't bet the R interpreter isn't faster than Pharo on some stats and numerical code: linking with BLAS and the mkl can do wonders... Now, what I'm working for is transparent heterogeneous GPU/Xeon Phi accelerated compute. I think the approach could be used for Pharo as well, but Eliot would be unhappy ;) Thierry

Jan. 22, 2016

Re: [Pharo-users] Dynamic Typing > Static Typing? Â« games.greggman.com

by stepharo

> Well spoken! > > Free software became a business enabler thanks to the web. Back then, there was no web, no ability to build global communities pushing forward a shared artefact. I think that is no coincidence that the oldest language that is still mainstream is C, which was used to build Unix, which was used to build the web. > > Now, let's do something awesome :-) Yes :) And business

Jan. 22, 2016

Re: [Pharo-users] Dynamic Typing > Static Typing? Â« games.greggman.com

by stepharo

> - Performance: for a compiler, having access to static types makes > compiling and performance optimisation a lot easier. This is my > current project (R compilation to heterogeneous targets) and I find > that type inference over R code is a hard (and interesting) subject. Thierry you see what I would love to have is a R to Pharo :)

Jan. 22, 2016

Re: [Pharo-users] (no subject)

by stepharo

Hi asbath I love your question :) have a look at the tutorial of gemstone http://seaside.gemtalksystems.com/tutorial/chapter12.pdf Stef Le 22/1/16 19:16, Asbath Sama biyalou via Pharo-users a Ã©crit :

Jan. 22, 2016

Seaside / .Net Job

by Ramon Leon

We're looking for a full time remote mid-level front-end Smalltalk/Seaside/? developer with some additional non Smalltalk skills. 4+ years experience or equivalent talent, with strong emphasis on front-end JavaScript and AJAX development. Must be skilled in client-side web technologies: HTML, CSS, JavaScript and jQuery (must have skills), Prototype (can learn). Must be familiar with tools like firebug/chrome and Visual Studio. Our primary application is a Seaside 2.8 web app running on Pharo 1.1 Smalltalk. A little out of date but it serves us well and it's in need of some additions. There won't be enough Smalltalk work for a full time position, so you need to have some additional skills with which we can keep you busy the rest of the time. So we're interested in either a Seaside Smalltalk / JavaScript guy, or a Seaside Smalltalk / .Net guy. We are interested in U.S. residents only, this is full time remote work 9 to 5 type thing. So if you're more the Smalltalk/JavaScript type please visit: http://www.alliancereservations.com/javascript-test.html and follow the instructions there, if you're the Smalltalk/.Net type please visit: http://www.alliancereservations.com/developer-test.html and follow the instructions there. Along with those, find a way to show me your Smalltalk/Seaside skills, I don't have a specific test for it, but your code is your resume; it's what I'm looking at. Compensation: 60-75k depending on skill set. -- Ramon Leon Chief Technical Officer Alliance Reservations Network

Jan. 22, 2016

Re: [Pharo-users] Dr. Geo Swiss App Store

by Hilaire

Hello Yuriy, It is not anymore in the Apple store because I did not upload a new build. Apple automatically remove it if you don't after one year. You can use the Android version however, it is still on the Google play store. The recent version of Dr. Geo (since 2013 I think) use the Athens canvas, it is not yet supported by the VM for Android and iOS. Therefore I had few interest to rebuild an aldready obsolete version of Dr. Geo for iOS. Hilaire -- Dr. Geo http://drgeo.eu

Jan. 22, 2016

Re: [Pharo-users] [From StackOverflow] How to parse ndjson in Pharo with NeoJSON

by MartinW

Sven Van Caekenberghe-2 wrote > Well, it is quite a bit of data (I didn't look too deeply), 50.000 records > of structured/nested data with quite a lot of strings. If each record is > 1Kb, that makes 50Mb. > > How do you measure your memory consumption ? What did you expect ? I did only think about memory, when my first attempts to parse the file reached the VM's memory limit, which seemed to be at ~500MB on OS X out of the box. Then I did only watch the memory from outside, using OS X's Activity Monitor and after I gave the VM more memory, the image grew up to 1.2 GB while parsing and inspecting the 80MB file. But I did not yet investigate, were the memory went - perhaps it is all in the Inspector that I opened to view the result :) Sven Van Caekenberghe-2 wrote > Right now, your JSON is parsed and the result is a combination of lists > (Array) and maps (Dictionary). If you know/understand well what is inside > it, and it is regular enough, you could try to build your own > specialised/optimised data/domain model for it. NeoJSON can also parse > directly to your objects, instead of the general ones (a process called > mapping). This is some work, of course, and it might not be worth it, > YMMV. Yes, I have used mappings in the past. Here I was just toying with the New York Public Library's Open Source data for a second... Sven Van Caekenberghe-2 wrote > Sven > >> I tried to parse with >> PetitParser but the results were similar. I guess, i have to learn to >> find >> out were all the memory goes. >> >> Best regards, >> Martin. >> >> >> >> Sven Van Caekenberghe-2 wrote >>> (I don't do StackOverflow) >>> >>> Reading the 'format' is easy, just keep on doing #next for each JSON >>> expression (whitespace is ignored). >>> >>> | data reader | >>> data := '{"smalltalk": "cool"} >>> {"pharo": "cooler"}'. >>> reader := NeoJSONReader on: data readStream. >>> Array streamContents: [ :out | >>> [ reader atEnd ] whileFalse: [ out nextPut: reader next ] ]. >>> >>> Preventing intermediary data structures is easy too, use streaming. >>> >>> | client reader data networkStream | >>> (client := ZnClient new) >>> streaming: true; >>> url: >>> 'https://github.com/NYPL-publicdomain/data-and-utilities/blob/master/items/p…'; >>> get. >>> networkStream := ZnCharacterReadStream on: client contents. >>> reader := NeoJSONReader on: networkStream. >>> data := Array streamContents: [ :out | >>> [ reader atEnd ] whileFalse: [ out nextPut: reader next ] ]. >>> client close. >>> data. >>> >>> It took a couple of seconds, it is 80MB+ over the network for 50K items >>> after all. >>> >>> >>> >>> HTH, >>> >>> Sven >>> >>> >>>> On 21 Jan 2016, at 12:02, Esteban Lorenzano < >> >>> estebanlm@ >> >>> > wrote: >>>> >>>> Hi, >>>> >>>> there is a question I donât know how to answer. >>>> >>>> http://stackoverflow.com/questions/34904337/how-to-parse-ndjson-in-pharo-wi… >>>> >>>> Transcript: >>>> >>>> I want to parse ndjson (newline delimited json) data with NeoJSON on >>>> Pharo Smalltalk. >>>> >>>> ndjson data looks like this: >>>> >>>> {"smalltalk": "cool"} >>>> {"pharo": "cooler"} >>>> At the moment I convert my file stream to a string, split it on newline >>>> and then parse the single parts using NeoJSON. This seems to use an >>>> unnecessary (and extremely huge) amount of memory and time, probably >>>> because of converting streams to strings and vice-versa all the time. >>>> What would be an efficient way to do this task? >>>> >>>> >>>> Takers? >>>> Esteban >>> >>> >>> >>> Screen Shot 2016-01-21 at 13.33.57.png (480K) >>> <http://forum.world.st/attachment/4873112/0/Screen%20Shot%202016-01-21%20at%2013.33.57.png> >> >> >> >> >> >> -- >> View this message in context: >> http://forum.world.st/From-StackOverflow-How-to-parse-ndjson-in-Pharo-with-… >> Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com. -- View this message in context: http://forum.world.st/From-StackOverflow-How-to-parse-ndjson-in-Pharo-with-… Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.

Jan. 22, 2016

Re: [Pharo-users] [From StackOverflow] How to parse ndjson in Pharo with NeoJSON

by Sven Van Caekenberghe

> On 22 Jan 2016, at 16:13, MartinW <wm(a)fastmail.fm> wrote: > > Thank you, Sven! (I asked the question on StackOverflow) > > And also let me thank you for NeoJSON, NeoCSV and Zinc, which I use a lot > and which are a joy to use! Also the documentation is very good and helps a > lot. Thanks, Martin. > Your code works well and I save a bit of memory by avoiding intermediary > data structures, but still this operation uses a lot more memory than I had > expected (the example file I use is 80 MB). Well, it is quite a bit of data (I didn't look too deeply), 50.000 records of structured/nested data with quite a lot of strings. If each record is 1Kb, that makes 50Mb. How do you measure your memory consumption ? What did you expect ? Right now, your JSON is parsed and the result is a combination of lists (Array) and maps (Dictionary). If you know/understand well what is inside it, and it is regular enough, you could try to build your own specialised/optimised data/domain model for it. NeoJSON can also parse directly to your objects, instead of the general ones (a process called mapping). This is some work, of course, and it might not be worth it, YMMV. Sven > I tried to parse with > PetitParser but the results were similar. I guess, i have to learn to find > out were all the memory goes. > > Best regards, > Martin. > > > > Sven Van Caekenberghe-2 wrote >> (I don't do StackOverflow) >> >> Reading the 'format' is easy, just keep on doing #next for each JSON >> expression (whitespace is ignored). >> >> | data reader | >> data := '{"smalltalk": "cool"} >> {"pharo": "cooler"}'. >> reader := NeoJSONReader on: data readStream. >> Array streamContents: [ :out | >> [ reader atEnd ] whileFalse: [ out nextPut: reader next ] ]. >> >> Preventing intermediary data structures is easy too, use streaming. >> >> | client reader data networkStream | >> (client := ZnClient new) >> streaming: true; >> url: >> 'https://github.com/NYPL-publicdomain/data-and-utilities/blob/master/items/p…'; >> get. >> networkStream := ZnCharacterReadStream on: client contents. >> reader := NeoJSONReader on: networkStream. >> data := Array streamContents: [ :out | >> [ reader atEnd ] whileFalse: [ out nextPut: reader next ] ]. >> client close. >> data. >> >> It took a couple of seconds, it is 80MB+ over the network for 50K items >> after all. >> >> >> >> HTH, >> >> Sven >> >> >>> On 21 Jan 2016, at 12:02, Esteban Lorenzano < > >> estebanlm@ > >> > wrote: >>> >>> Hi, >>> >>> there is a question I donât know how to answer. >>> >>> http://stackoverflow.com/questions/34904337/how-to-parse-ndjson-in-pharo-wi… >>> >>> Transcript: >>> >>> I want to parse ndjson (newline delimited json) data with NeoJSON on >>> Pharo Smalltalk. >>> >>> ndjson data looks like this: >>> >>> {"smalltalk": "cool"} >>> {"pharo": "cooler"} >>> At the moment I convert my file stream to a string, split it on newline >>> and then parse the single parts using NeoJSON. This seems to use an >>> unnecessary (and extremely huge) amount of memory and time, probably >>> because of converting streams to strings and vice-versa all the time. >>> What would be an efficient way to do this task? >>> >>> >>> Takers? >>> Esteban >> >> >> >> Screen Shot 2016-01-21 at 13.33.57.png (480K) >> <http://forum.world.st/attachment/4873112/0/Screen%20Shot%202016-01-21%20at%2013.33.57.png> > > > > > > -- > View this message in context: http://forum.world.st/From-StackOverflow-How-to-parse-ndjson-in-Pharo-with-… > Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.

Jan. 22, 2016