December 2015 - Pharo-dev - lists.pharo.org

Re: [Pharo-dev] [Moose-dev] Roassal2 in Pharo 5 -> segfault

by Johan Fabry

> On Dec 30, 2015, at 07:51, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > > Hi, > > Iâve seen this aroundâ¦ I think is because a problem copying memoryâ¦ I will check it (next week, Iâm on holidays now) but I would like to have a bug report, please. Done! https://pharo.fogbugz.com/f/cases/17309/Roassal2-in-Pharo-5-produces-a-segf… Are you In Argentina for new year? Feliz aÃ±o nuevo and enjoy the asado! :-) > btwâ¦ the crashes are not related to Spur but the new FFI implementation (and the migration from old NativeBoost). Spur itself is pretty stable :) Great! Now just to get the FFI to be as stable as Spur ;-) ---> Save our in-boxes! http://emailcharter.org <--- Johan Fabry - http://pleiad.cl/~jfabry PLEIAD and RyCh labs - Computer Science Department (DCC) - University of Chile

Dec. 30, 2015

Making "Cmd-." reliable?

by Alexandre Bergel

Hi! Since some of us are deep into the VM memory model. Can we take this opportunity to have a reliable execution interruption mechanism? Cheers, Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

Dec. 30, 2015

Re: [Pharo-dev] Small pillar question

by Ferlicot D. Cyril

Le 30/12/2015 16:17, Alexandre Bergel a Ã©crit : > Hi! > > How can I write == in a code format? > == == == obviously does not parse wellâ¦ > > Any alternative? Hi, ==\=\=== > > Cheers, > Alexandre > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > -- Cyril Ferlicot http://www.synectique.eu 165 Avenue Bretagne Lille 59000 France

Dec. 30, 2015

Re: [Pharo-dev] Small pillar question

by Dimitris Chloupis

i dont get this , code snippets are not affected by the pillar syntax. maybe you mean as part of the main body of documentation using pillar syntax ? in that case just use the escape character \ which will force pillar not to see the next character as part of its syntax. On Wed, Dec 30, 2015 at 5:18 PM Alexandre Bergel <alexandre.bergel(a)me.com> wrote: > Hi! > > How can I write == in a code format? > == == == obviously does not parse wellâ¦ > > Any alternative? > > Cheers, > Alexandre > > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > >

Dec. 30, 2015

Small pillar question

by Alexandre Bergel

Hi! How can I write == in a code format? == == == obviously does not parse wellâ¦ Any alternative? Cheers, Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

Dec. 30, 2015

Re: [Pharo-dev] [Pharo-users] NeoJSON: parsing mapped nil fields

by Sven Van Caekenberghe

Hi, (Other comments in line). I added a new feature: === Name: Neo-JSON-Core-SvenVanCaekenberghe.31 Author: SvenVanCaekenberghe Time: 30 December 2015, 12:31:59.303349 pm UUID: fb235526-3c04-4e5f-a543-9a7e9eaaac2a Ancestors: Neo-JSON-Core-SvenVanCaekenberghe.30 New #allowNil option to Object mapping so that null values are accepted and returned as nil when reading a schema using #nextAs: (off by default) Added NeoJSONObjectMapping>>#allowNil Added NeoJSONReaderTests>>#testAllowNil === Name: Neo-JSON-Tests-SvenVanCaekenberghe.31 Author: SvenVanCaekenberghe Time: 30 December 2015, 12:32:13.455009 pm UUID: 650b4ecf-c9d9-40a5-a988-e4e3801faa42 Ancestors: Neo-JSON-Tests-SvenVanCaekenberghe.30 New #allowNil option to Object mapping so that null values are accepted and returned as nil when reading a schema using #nextAs: (off by default) Added NeoJSONObjectMapping>>#allowNil Added NeoJSONReaderTests>>#testAllowNil === >From the unit test, this allows you to do as follows: self assert: ((NeoJSONReader on: 'null' readStream) mapInstVarsFor: Point; for: Point do: [ :mapping | mapping allowNil ]; nextAs: Point) equals: nil. self assert: ((NeoJSONReader on: '[ { "x" : 1, "y" : 2 }, null, { "x" : 3, "y" : -1 } ]' readStream) mapInstVarsFor: Point; for: Point do: [ :mapping | mapping allowNil ]; for: #ArrayOfPoints customDo: [ :mapping | mapping listOfElementSchema: Point ]; nextAs: #ArrayOfPoints) equals: { 1 @ 2. nil. 3 @ -1 }. I decided to make this a per mapping option, not a per reader option. > On 23 Dec 2015, at 11:19, Skip Lentz <skip.lentz(a)inria.fr> wrote: > > Hi, thanks for replying! I can share some ideas. > >> On Dec 23, 2015, at 12:09 AM, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: >> >> Hi, >> >> NeoJSON does have a bit of a split personality. > > Yes, this is what I noticed. Apart from this, I think itâs an awesome library, and I thank you a lot for making it. > It might be good to not make a distinction between #nextAs: and #next, and only rely on #nextAs:. Then #next might be rewritten as such: > > NeoJSONReader>>next > > ^ self nextAs: self mapClass > > Donât know if that makes sense or not. It might alleviate this split personality, as you put it. No, that would not help ;-) The two approaches are fundamentally different: either you accept anything that is present (dynamic mode), returning lists (Arrays) and maps (Dictionaries), or you accept a schema that is predefined (static mode). >> When you use mappings and #nextAs: it tries to map a static type structure on what is coming in. As such it is not really prepared for dynamic surprises like objects being replaced by null. > > Yes, in the general case, once youâve sent #nextAs: to the reader with your value schema, youâre âstuckâ with that exact schema. > > While working on the bindings for the GitHub API, there are some JSON representations which send a âtypeâ field (e.g. âtypeâ : âcommitâ). > I would like it to be possible to change the class schema to that of a subclass of the original class when detecting a combination of fields. > > That is, I specify a combination of fields, and if any is present, then change the class of the current object to a subclass. By specifying combinations of fields, you don't rely on the order in which they appear in the JSON. > > Maybe in this way it is possible to accomplish without giving up the nice property of NeoJSON not making intermediate structures? Sounds tough to do without turning it into a hack though.. I know what you mean, there are 2 common approaches (some would call it a wrong way to use JSON, but that is another discussion): { "type":"Point", "x":1, "y":2 } or { "type":"Point", "value": {"x":1, "y":2} } (Type could be class, or whatever). The first case is bad, you have to read everything before you can make a decision, which IMO kills the advantage of mapping while trying to avoid intermediate structures (i.e. you could do the mapping yourself afterwards). The second case is a bit better, but not much. Both top level elements could have switched place, in which case you already have to read the value, not knowing what to map it to. You could try experimenting with Custom mappings, they allow arbitrary conversions, but I doubt if you could really prevent intermediate structure creation. But maybe I just don't see it right, and it is possible after all. If the returned JSON is highly dynamic and variable, I would just use dynamic mode and then in a second pass convert the maps/lists to domain objects myself. Or someone should write a generic maps/lists to domain model objects mapper (independent of JSON). >> Do also note that the typing info is totally absent from the JSON itself, unlike STON for example. NeoJSON also tries (and succeeds) in maintaining a stream based parser that does not generate intermediate structures except your own domain models. >> >> But your request does make sense and I will think about it. It might be possible. It has been a while that I really thought about the implementation. > > Alright, Iâm willing to help if needed. We can discuss in this e-mail thread. Thanks for the feedback/discussion. Regards, Sven

Dec. 30, 2015

Re: [Pharo-dev] [Moose-dev] Roassal2 in Pharo 5 -> segfault

by Esteban Lorenzano

Hi, Iâve seen this aroundâ¦ I think is because a problem copying memoryâ¦ I will check it (next week, Iâm on holidays now) but I would like to have a bug report, please. btwâ¦ the crashes are not related to Spur but the new FFI implementation (and the migration from old NativeBoost). Spur itself is pretty stable :) Esteban > On 29 Dec 2015, at 19:59, Alexandre Bergel <alexandre.bergel(a)me.com> wrote: > > I have also seen some random crashes using Spurâ¦ > > Alexandre > -- > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > Alexandre Bergel http://www.bergel.eu <http://www.bergel.eu/> > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > >> On Dec 29, 2015, at 2:33 PM, Johan Fabry <jfabry(a)dcc.uchile.cl <mailto:jfabry@dcc.uchile.cl>> wrote: >> >> Hi all, >> >> just in case this is not a known bug: Intensive use of Roassal2 in Pharo 5 causes a segfault of the mac vm. A crash.dump is attached. Itâs the vm I got just now ( wget --quiet -O - get.pharo.org/50+vm <http://get.pharo.org/50+vm> | bash ) and Pharo5 with Alexesâ 17280 slice to make Roassal visualize shapes correctly. >> >> To reproduce, all I need to do is have a visualization open with a layout animation and after some time it will crash. I use this in LRP and I can give easy steps to reproduce if needed. >> >> <crash.dmp> >> >> ---> Save our in-boxes! http://emailcharter.org <http://emailcharter.org/> <--- >> >> Johan Fabry - http://pleiad.cl/~jfabry <http://pleiad.cl/~jfabry> >> PLEIAD and RyCh labs - Computer Science Department (DCC) - University of Chile >> >> _______________________________________________ >> Moose-dev mailing list >> Moose-dev(a)list.inf.unibe.ch <mailto:Moose-dev@list.inf.unibe.ch> >> https://www.list.inf.unibe.ch/listinfo/moose-dev >

Dec. 30, 2015

Re: [Pharo-dev] pillar question

by Damien Cassou

On December 29, 2015 5:56:02 PM GMT+01:00, "ClÃ©ment Bera" <bera.clement(a)gmail.com> wrote: >Is this the right place to ask questions about pillar ? > >I am trying to write documentation using pillar. I am now stuck at >conditional printing and on the contrary to my previous issues I didn't >find examples in other documentation written in pillar. > >In latex, I would do conditional printing this way: > >\newif \ifsol >\sol true >\ifsol paragraph display if sol is true \fi > >and depending if I put true or false in the variable sol, the paragraph >is >displayed or not. > >Then I can print two version of my document with different texts at >specific parts depending on this variable. > >I tried multiple ways in pillar, but I can't achieve the same result. >What >is the right way to do conditional printing in pillar ? We don't have this. But, you can use annotated paragraphs to do the same: @@hidden blabla In LaTeX, this generates a blabla environment and in HTML a div with a blabla class. You can then use latex/css tricks to show or hide these blocks -- Damien Cassou http://damiencassou.seasidehosting.st "Success is the ability to go from one failure to another without losing enthusiasm." --Winston Churchill

Dec. 30, 2015

Re: [Pharo-dev] Kafka protocol

by Robert Withers

> On Dec 29, 2015, at 19:50, Ben Coman <btc(a)openinworld.com> wrote: > > On Tue, Dec 29, 2015 at 11:20 PM, Dimitris Chloupis > <kilon.alios(a)gmail.com> wrote: >> Should be ? There is no "should be" it is what it is, if anyone wants >> something more he is more than welcomed to stop writing to the mailing list >> and use that time instead to sit his ass down and make the code. > > I think Its okay to sometimes advocate for features. The *hope* of > course is that the idea sparks the interest of others. It just needs > to be moderated by: expectation, channel noise and own-effort (as you > say). The word "should" is a loaded term with a subtle difference in > two > 1. used to indicate obligation, duty, or correctness, typically when > criticizing someone's actions. > 2. used to indicate what is probably [a good idea]. +1 Thank you for putting it so clearly. Robert > > I often fall in the trap of meaning the second, but my wife hears the > first --> trouble. > cheers -ben > >> The >> potential of Pharo is unlimited but taking advantage of it is hard work and >> nothing else. BigData frameworks dont come from BigWords. >> >> I wanted Pharo to work with python and use python libraries . Did I came to >> this mailing list to write that pharo "should be" able to use python >> libraries, because python is super popular and its constantly growing ? >> >> Nope ! >> >> I sat down my ass and worked hard to make it happen and I did accomplish it. >> Still much to improve but there is no substitute to hard work and putting >> the time to improve pharo. >> >> You wanna use Jars from Pharo , no problemo, work hard and do it. But please >> dont tell me what should be in the vision of Pharo, why BigData and not 3d >> graphics, why 3d graphics and not network libraries, why network libraries >> and not more IDE tools, why IDE tools and not more advanced language >> features, why advance language features and not a C API , why C API and not >> web development frameworks ? >> >> In the end nothing , NOTHING , should be outside the scope of a language >> that wants to call itself "turing complete" . No goal is higher than >> something else. Each coders has different needs . What it "Should be" is >> people that are willing to work hard to make THEIR OWN NEEDS a reality using >> a tool THEY LOVE using. Its a choice. >> >> And a Stef so well says it >> >> Pharo is Yours >> >> On Mon, Dec 28, 2015 at 9:44 PM Robert Withers <robert.w.withers(a)gmail.com> >> wrote: >>> >>> What I mean is that an undertaking of this scope should be in the Vision >>> and on the roadman for Pharo, with a broader concerted commitment to >>> enterprise BigData integration. >>> >>> robert >>> >>>> On 12/28/2015 02:29 PM, Robert Withers wrote: >>>> >>>> >>>>> On 12/28/2015 12:19 PM, Frank Shearar wrote: >>>>> On 27 December 2015 at 16:11, Robert Withers >>>>> <robert.w.withers(a)gmail.com> wrote: >>>>>> This would be awesome in Pharo: >>>>>> >>>>>> https://cwiki.apache.org/confluence/display/KAFKA/A+Guide+To+The+Kafka+Prot…. >>>>>> >>>>>> Since we cannot yet call JARs, implementing the wire protocol and API >>>>>> proxies would really be huge from an enterprise pharo standpoint. If >>>>>> other >>>>>> folks are interested in working on this, I could help out. >>>>> Having a Kafka client in Pharo would indeed be awesome. But who cares >>>>> about calling JARs? It's a wire protocol; write a client against that >>>>> and you're done. >>>> >>>> Yes, although I would still like to load JARs, but for different >>>> reasons. That aside, yes implementing the wire protocol would be >>>> really happening. I'll help. I don't want to own it. It would >>>> definitely be enterprise. >>>> >>>> robert >>>> >>>> >>>>> >>>>> frank >>> >>> -- >>> Robert >>> . .. ... ^,^ >

Dec. 30, 2015

Re: [Pharo-dev] Kafka protocol

by Ben Coman

On Tue, Dec 29, 2015 at 11:20 PM, Dimitris Chloupis <kilon.alios(a)gmail.com> wrote: > Should be ? There is no "should be" it is what it is, if anyone wants > something more he is more than welcomed to stop writing to the mailing list > and use that time instead to sit his ass down and make the code. I think Its okay to sometimes advocate for features. The *hope* of course is that the idea sparks the interest of others. It just needs to be moderated by: expectation, channel noise and own-effort (as you say). The word "should" is a loaded term with a subtle difference in two 1. used to indicate obligation, duty, or correctness, typically when criticizing someone's actions. 2. used to indicate what is probably [a good idea]. I often fall in the trap of meaning the second, but my wife hears the first --> trouble. cheers -ben > The > potential of Pharo is unlimited but taking advantage of it is hard work and > nothing else. BigData frameworks dont come from BigWords. > > I wanted Pharo to work with python and use python libraries . Did I came to > this mailing list to write that pharo "should be" able to use python > libraries, because python is super popular and its constantly growing ? > > Nope ! > > I sat down my ass and worked hard to make it happen and I did accomplish it. > Still much to improve but there is no substitute to hard work and putting > the time to improve pharo. > > You wanna use Jars from Pharo , no problemo, work hard and do it. But please > dont tell me what should be in the vision of Pharo, why BigData and not 3d > graphics, why 3d graphics and not network libraries, why network libraries > and not more IDE tools, why IDE tools and not more advanced language > features, why advance language features and not a C API , why C API and not > web development frameworks ? > > In the end nothing , NOTHING , should be outside the scope of a language > that wants to call itself "turing complete" . No goal is higher than > something else. Each coders has different needs . What it "Should be" is > people that are willing to work hard to make THEIR OWN NEEDS a reality using > a tool THEY LOVE using. Its a choice. > > And a Stef so well says it > > Pharo is Yours > > On Mon, Dec 28, 2015 at 9:44 PM Robert Withers <robert.w.withers(a)gmail.com> > wrote: >> >> What I mean is that an undertaking of this scope should be in the Vision >> and on the roadman for Pharo, with a broader concerted commitment to >> enterprise BigData integration. >> >> robert >> >> On 12/28/2015 02:29 PM, Robert Withers wrote: >> > >> > >> > On 12/28/2015 12:19 PM, Frank Shearar wrote: >> >> On 27 December 2015 at 16:11, Robert Withers >> >> <robert.w.withers(a)gmail.com> wrote: >> >>> This would be awesome in Pharo: >> >>> >> >>> https://cwiki.apache.org/confluence/display/KAFKA/A+Guide+To+The+Kafka+Prot…. >> >>> >> >>> Since we cannot yet call JARs, implementing the wire protocol and API >> >>> proxies would really be huge from an enterprise pharo standpoint. If >> >>> other >> >>> folks are interested in working on this, I could help out. >> >> Having a Kafka client in Pharo would indeed be awesome. But who cares >> >> about calling JARs? It's a wire protocol; write a client against that >> >> and you're done. >> > >> > Yes, although I would still like to load JARs, but for different >> > reasons. That aside, yes implementing the wire protocol would be >> > really happening. I'll help. I don't want to own it. It would >> > definitely be enterprise. >> > >> > robert >> > >> > >> >> >> >> frank >> >> >> > >> >> -- >> Robert >> . .. ... ^,^ >> >> >

Dec. 30, 2015