March 2014 - Pharo-dev - lists.pharo.org

Re: [Pharo-dev] [Moose-dev] [Pharo-business] [ANN] DBPedia: Query Wikipedia from Pharo

by Norbert Hartl

Am 03.03.2014 um 14:22 schrieb Johan Fabry <jfabry(a)dcc.uchile.cl>: > +1 to that! It would be good to have some kind of uniform syntax for constructing queries. Especially now that the use of JSON objects is quite common. > I would like to have that, too. I need to have query support for elasticsearch and I would do something similar like MongoQueries. The idea of having a common query syntax is nice but Iâm not convinced it will be easy to do. The parser needs to be easily extendable because most applications will have their custom additions to the base syntax. Norbert > The OP was actually referring to MongoQueries. To get some examples of the syntax see section 4 of https://ci.inria.fr/pharo-contribution/job/PharoForTheEnterprise/lastSucces… > > On Mar 3, 2014, at 10:13 AM, Alexandre Bergel <alexandre.bergel(a)me.com> wrote: > >>> What would be nice is to have an abstraction like mongoTalk on top to avoid to manipulate strings but to manipulate query elements. >> >> That is a nice idea. >> >> Alexandre > > > > ---> Save our in-boxes! http://emailcharter.org <--- > > Johan Fabry - http://pleiad.cl/~jfabry > PLEIAD lab - Computer Science Department (DCC) - University of Chile > >

March 9, 2014

Re: [Pharo-dev] base64.b64encode(data) equivalent

by Sven Van Caekenberghe

ZnBase64Encoder new encode: 42 asByteArray. => 'Kg==' (ZnBase64Encoder new decode: 'Kg==') asInteger. => 42 There is also #asByteArrayOfSize: and signed/unsigned might come into play as well. Note that strictly speaking (as implemented by ZnBase64Encoder), Base64 is a binary to string encoding. But is it often used string to string (as in #base64Encoded and #base64Decoded, which are still implemented using Base64MimeConverter) but the explicit correct way is as in ZnUtils #encodeBase64: and #decodeBase64: using a character encoding. On 09 Mar 2014, at 09:09, Pharo4Stef <pharo4Stef(a)free.fr> wrote: > around Zinc-Character-Encoding-Core > :) > > Stef > On 09 Mar 2014, at 09:07, Pharo4Stef <pharo4Stef(a)free.fr> wrote: > >> Iâm sure that we have that. I remember svenâs code using encoder >> but I do not know where. >> >> # Method for encoding ints with base64 encoding >> def encode(n): >> data = struct.pack("i", n) >> s = base64.b64encode(data) >> return s >> >

March 9, 2014

Re: [Pharo-dev] base64.b64encode(data) equivalent

by Pharo4Stef

around Zinc-Character-Encoding-Core :) Stef On 09 Mar 2014, at 09:07, Pharo4Stef <pharo4Stef(a)free.fr> wrote: > Iâm sure that we have that. I remember svenâs code using encoder > but I do not know where. > > # Method for encoding ints with base64 encoding > def encode(n): > data = struct.pack("i", n) > s = base64.b64encode(data) > return s >

March 9, 2014

base64.b64encode(data) equivalent

by Pharo4Stef

Iâm sure that we have that. I remember svenâs code using encoder but I do not know where. # Method for encoding ints with base64 encoding def encode(n): data = struct.pack("i", n) s = base64.b64encode(data) return s

March 9, 2014

Re: [Pharo-dev] Smalltalk tools: explore failing in 3.0

by Pharo4Stef

I do not know the code of the inspector (we fixed the processes use friday with clement) and I got not resolve the problem in less than 10min > > On 08 Mar 2014, at 08:33, phil(a)highoctane.be wrote: > >> If I do inspect >> >> Smalltalk tools >> >> it works. >> >> But explore crashes. >> >> How is that? > > not tested :) > We will fix that. Probably nothing >> >> Phil > >

March 9, 2014

Re: [Pharo-dev] Smalltalk tools: explore failing in 3.0

by phil＠highoctane.be

On Sat, Mar 8, 2014 at 11:07 PM, <btc(a)openinworld.com> wrote: > phil(a)highoctane.be wrote: > >> If I do inspect >> >> Smalltalk tools >> it works. >> >> But explore crashes. >> >> How is that? >> >> Phil >> > That is worth logging a must-fix bug. > > https://pharo.fogbugz.com/default.asp?13058 --- Phil

March 9, 2014

Re: [Pharo-dev] Pharo3.0 and Halos: very annoying to work with

by phil＠highoctane.be

On Sat, Mar 8, 2014 at 11:00 PM, <btc(a)openinworld.com> wrote: > phil(a)highoctane.be wrote: > > I am working on moving TWM to 3.0 and the way morphs are controlled now > is really annoying. > > Now, we get the new menu when doing the special clicking (e.g. > Shift-Alt-Click in Windows, Cmd-Shift Click in OSX). > > How is one now supposed to be accessing the internal morphs by clicking > multiple times and having the halo follow suit? > > The menu prevents that as it gets in the way. > > Thanks. > > Phil > > > > ------------------------------ > > > Not sure what you mean. Attached image shows halos after a single > <Shift-Alt-Click> in Windows 7 build 30780. > cheers -ben > Latest build, Windows 8.1 gives me the attached picture. Only when doing "add halos" in the menu showing up do we get halos. Phil

March 9, 2014

Re: [Pharo-dev] Is there some shared memory space?

by Max Leske

On 08.03.2014, at 23:12, btc(a)openInWorld.com wrote: > Max Leske wrote: >> >> >> On 08.03.2014, at 15:03, Guillermo Polito <guillermopolito(a)gmail.com> wrote: >> >>> Hmm, as far as I know there is no "shared memory space"... or bah.. what do you mean by that? >>> >>> From my understanding I'd say that when you do: >>> >>> "- I fix the bug (i.e., commenting the self error)" >>> >>> you introduce some side effect that causes an infinite recursion => lots of contexts are reified because the vm stack gets full => you run out of memory >> >> No, it seems that the error lies with Fuel, although I canât yet say why. Iâm still investigating. >> >> Max > > Max, You've been able to reproduce the problem? Not really. Iâm working on it with Roberto and post back once weâve figured out more. Iâm pretty sure though that VM and image are fine (apart from limiting the heap size to 500MB *grml*). > >> >>> >>> BTW, are you on windows, linux, mac? which vm/image? >>> >>> Guille >>> >>> >>> On Sat, Mar 8, 2014 at 2:55 PM, roberto.minelli(a)usi.ch <roberto.minelli(a)usi.ch> wrote: >>> Anyone on this? It is very frustrating for me. >>> >>> Cheers, >>> Roby >>> >>> On Mar 7, 2014, at 1:05 PM, roberto.minelli(a)usi.ch wrote: >>> >>> > >>> > On Mar 7, 2014, at 12:24 PM, Max Leske <maxleske(a)gmail.com> wrote: >>> > >>> >> >>> >> On 07.03.2014, at 11:55, roberto.minelli(a)usi.ch wrote: >>> >> >>> >>> Hi guys, >>> >>> >>> >>> I am experiencing a very strange problem that makes me think there is some shared memory problem with Pharo. >>> >>> >>> >>> Here are the steps that lead to the problem: >>> >>> - I have an image, I do something (i.e., materializing objects with Fuel) >>> >>> - I encounter a problem and a debugger pops up with a âself error: something" >>> >>> - I close the debugger >>> >>> - I close the image >>> >> >>> >> Do you save the image? If so, are you saving references to the already materialized objects? >>> > >>> > Of course, I did not save the image. Otherwise Iâd have understood the behavior. >>> > >>> >> >>> >>> - I reopen the image >>> >>> - I fix the bug (i.e., commenting the self error) >>> >>> - I re-run the same thing as in the first step >>> >>> - An OutOfMemory error appears. >>> >>> >>> >>> Any clue? >>> >>> >>> >>> Thanks, >>> >>> Roberto >>> >>> >>> >> >

March 8, 2014

Re: [Pharo-dev] Is there some shared memory space?

by btc＠openinworld.com

March 8, 2014

Re: [Pharo-dev] Smalltalk tools: explore failing in 3.0

by btc＠openinworld.com

phil(a)highoctane.be wrote: > If I do inspect > > Smalltalk tools > > it works. > > But explore crashes. > > How is that? > > Phil That is worth logging a must-fix bug.

March 8, 2014