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

Re: [Pharo-users] (no subject)

by Paul DeBruicker

Pharo Smalltalk Users mailing list wrote > I want to know how to use sessions in seaside to manage identification of > users. Thank you there is a Seaside specific mailing list here: http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside Generally when a user signs in you store them in a user instance variable in your session . When they sign out you nil that variable. You can then access them inside your components with self session user A system for doing user authentication and management (password recovery etc) with Seaside is TFLogin here: http://www.squeaksource.com/TFLogin.html If it doesn't load into the most recent Seaside or Pharo post on the Seaside list and we will get it working -- View this message in context: http://forum.world.st/no-subject-tp4873374p4873397.html 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 MartinW

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. 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). 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

(no subject)

by Asbath Sama biyalou

I want to know how to use sessions in seaside to manage identification of users. Thank you

Jan. 22, 2016

Re: [Pharo-users] Use cases for methods with optional parameters

by Jose San Leandro

Hi, For the sake of simplifying APIs by not asking the client to provide everything, and at the same time for the sake of not constraining other clients with different use cases in which they need to provided all parameters, I've often relied on that kind of ugly overloaded style. APIs are difficult to change afterwards, so they have to be simple enough for the expected use case, but flexible enough for unexpected use cases. I'd vote +1 for optional parameters with default values. 2016-01-22 9:00 GMT+01:00 phil(a)highoctane.be <phil(a)highoctane.be>: > This would be nice to be able to use several different languages "ways of > doing things" that would translate into message sends behind the scenes. > > Helvetia story... > > Phil > > On Thu, Jan 21, 2016 at 6:04 PM, Esteban A. Maringolo < > emaringolo(a)gmail.com> wrote: > >> 2016-01-21 8:38 GMT-03:00 Henrik Johansen <henrik.s.johansen(a)veloxit.no>: >> > >> >> On 20 Jan 2016, at 6:14 , Esteban A. Maringolo <emaringolo(a)gmail.com> >> wrote: >> >> >> >> >> >> I would be interested in the use cases and how to deal with >> >> "undefined" arguments, will they be nil or other kind of undefined >> >> object? >> >> > Perhaps >> > >> > request: aFile with: anotherThing and: aThirdThing >> > <optionalParameter: anotherThing "default: nil"> >> > <optionalParameter: aThirdThing default: defaultThirdThing> >> > -> >> > request: aFile with: anotherThing >> > ^self request: aFile with: anotherThing and: self >> defaultThirdThing >> > request: aFile and:: aThirdThing >> > ^self request: aFile with: nil and: self aThirdThing >> > request: aFile >> > ^self request: aFile with: nil and: self defaultThirdThing >> >> >> The pragma for the default unless it's a literal object it should be a >> message send. >> >> I still have to see a good use case that could justify the use of >> that. Because it also involves the message lookup, which AFAIK is >> performed by the VM. >> >> Regards, >> >> Esteban A. Maringolo >> >> >> >

Jan. 22, 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). ah, i understand werner

Jan. 22, 2016

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

by Nicolai Hess

2016-01-22 13:26 GMT+01:00 Werner Kassens <wkassens(a)libello.com>: > On 01/22/2016 01:16 PM, Tudor Girba wrote: > > I do not understand this one. Could you describe more specifically the >> scenario? >> > > if i do a "debug test" in the contextmenu of "testGenericCharCall" (in > FFIPluginTests) and press "restart" then "= 130" is highlighted. > werner > > > 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).

Jan. 22, 2016

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

by Werner Kassens

On 01/22/2016 01:16 PM, Tudor Girba wrote: > I do not understand this one. Could you describe more specifically the scenario? if i do a "debug test" in the contextmenu of "testGenericCharCall" (in FFIPluginTests) and press "restart" then "= 130" is highlighted. werner

Jan. 22, 2016

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

by Tudor Girba

Hi, > On Jan 22, 2016, at 12:53 PM, Werner Kassens <wkassens(a)libello.com> wrote: > > On 01/22/2016 11:48 AM, Tudor Girba wrote: >> Hi, >> >> Yes. That is the type of input that we need. >> >> It would be great if others would do the same. > > Hi Doru, > ok, i often use the debugger to test that some code actually does what i intended: > in the old one i click first on "stack top" and then click through the code with "into" and "over" and simply watch the results in "stack top". > with the new debugger "stack top" is gone, in the old one it was immediately reachable, since it was very much on the top of that small pane (no scrolling). Thanks. Indeed, we will add stackTop and thisContext back. They were present when we first integrated, but some said they are not useful for them. > additionally "into" and "over" became smaller buttons farther away from the variables section, iow more difficult to hit while also watching the lower pane. and btw if i do that on tests, the debugger does not really start at the beginning of the test (also restart does not help),eg open a debugger in 5.0 on FFIPluginTests>>testGenericCharCall and do a "restart": you are at the very end of the test. I do not understand this one. Could you describe more specifically the scenario? Doru > werner > -- www.tudorgirba.com www.feenk.com "From an abstract enough point of view, any two things are similar."

Jan. 22, 2016

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

by Werner Kassens

On 01/22/2016 11:48 AM, Tudor Girba wrote: > Hi, > > Yes. That is the type of input that we need. > > It would be great if others would do the same. Hi Doru, ok, i often use the debugger to test that some code actually does what i intended: in the old one i click first on "stack top" and then click through the code with "into" and "over" and simply watch the results in "stack top". with the new debugger "stack top" is gone, in the old one it was immediately reachable, since it was very much on the top of that small pane (no scrolling). additionally "into" and "over" became smaller buttons farther away from the variables section, iow more difficult to hit while also watching the lower pane. and btw if i do that on tests, the debugger does not really start at the beginning of the test (also restart does not help),eg open a debugger in 5.0 on FFIPluginTests>>testGenericCharCall and do a "restart": you are at the very end of the test. werner

Jan. 22, 2016

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

by Tudor Girba

Hi, Yes. That is the type of input that we need. It would be great if others would do the same. Cheers, Doru > On Jan 22, 2016, at 11:42 AM, stepharo <stepharo(a)free.fr> wrote: > > Hi guys > > Many of you may bthink that I'm mad or whatever about new UI elements. Sometimes this is true :) > but most of the time not. I'm just going straight and (harsh) comments. > So what I propose to the GT team is the following: > I'm ready to be a guinea pig > Each time they want I will record a screenflow of my interaction or perception about new/different tools. > I will follow a UI debugging process an expert proposed: talking aloud about my hypotheses while interacting and > discovering the tools. I play that in the past with other people and it works well. > > I encourage other people to do the same to give feeback to GT team. > > Stef > -- www.tudorgirba.com www.feenk.com "Speaking louder won't make the point worthier."

Jan. 22, 2016