- Pharo-users - lists.pharo.org

Re: [Pharo-users] DNU on materializing a fueled out exception

by Denis Kudriashov

2016-12-19 18:34 GMT+01:00 Denis Kudriashov <dionisiydk(a)gmail.com>: > 016-12-19 18:08 GMT+01:00 Max Leske <maxleske(a)gmail.com>: > >> I suppose that functionality should be resolved via FuelPlatform. >> Something like >> >> FLPlatform current >> openDebuggerOn: Processor activeProcess >> context: materialization root >> label: 'External stack' >> > As solution to current approach I agree here: it should be resolved by platform

Dec. 19, 2016

Re: [Pharo-users] DNU on materializing a fueled out exception

by Denis Kudriashov

Hi. 2016-12-19 18:08 GMT+01:00 Max Leske <maxleske(a)gmail.com>: > I suppose that functionality should be resolved via FuelPlatform. > Something like > > FLPlatform current > openDebuggerOn: Processor activeProcess > context: materialization root > label: 'External stack' > Is it really nice way to do it? I mean why we force system to open debugger when serialised context is loaded? IMHO it is responsibility of tool to decide what to do with object. It should be good extension for file browser or inspector. Tool will detect that it work with context and will allow to debug it. Post materialisation action is nice feature but for me it is overused here.

Dec. 19, 2016

Password storage options

by Jan BlizniÄenko

Hello I'm working on Pharo-based webserver and right now I got to the topic of storing user passwords. I found SHA256 integrated in Pharo, but hashing with SHA is far from enough. I also looked around the mailing list history to find few posts from 2011 about bcrypt using Linux libraries. I'd like to ask what is current status - what are my options under following conditions: I prefer Pharo 5 compatibility. I could downgrade to Pharo 4 or use beta Pharo 6, but latest stable relase is preferred. I require at least bcrypt or PDKBF2, but I much more prefer GPU-attack-resistant solutions like scrypt or Argon2. I require Linux compatibility, but platform independent solution would be kinda nice (we could use the same algorithm on our local machines with Mac and Win for development). Thank you Jan -- View this message in context: http://forum.world.st/Password-storage-options-tp4927471.html Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.

Dec. 19, 2016

Re: [Pharo-users] DNU on materializing a fueled out exception

by Max Leske

I suppose that functionality should be resolved via FuelPlatform. Something like FLPlatform current openDebuggerOn: Processor activeProcess context: materialization root label: 'External stack' That method can then be overriden accoring to the platform. https://github.com/theseion/Fuel/issues/222 <https://github.com/theseion/Fuel/issues/222> > On 19 Dec 2016, at 15:12, Mariano Martinez Peck <marianopeck(a)gmail.com> wrote: > > > > On Mon, Dec 19, 2016 at 4:53 AM, Holger Freyther <holger(a)freyther.de <mailto:holger@freyther.de>> wrote: > Hi, > > I showed Pharo to a friend and wanted to show the nice feature of fueling out an exception and then using FLMaterializer class>>#materializeFromFileNamed: to load it back and get a debugger up. In Pharo5 I am presented a DNU instead. > Holger, did you load Fuel explicitly or did you use the version that's already in Pharo 5? In the latter case we'll have to port that fix back to Pharo 5. Cheers, Max > > Hi Holger, > > I hope you were able to show that example to him anyways. That example make us won the first price at ESUG awards hahaha. I still remember when I was sitting at home, trying to think of a good example to show and I thought: "what if I serialize the debugger and the stack to another image?". I tried and it worked out of the box. One of the happiest dev programming days ever hahaha. > > > The DNU is on GTGenericStackDebugger as it doesn't understand the message Fuel is sending. What to fix, Fuel to use the new protocol or GTGenericStackDebugger to honor the old protocol? > > FueldOutStackDebugAction>>#serializeTestFailureContext: aContext toFileNamed: aFilename > | serializer | > > serializer := FLSerializer newDefault. > self encodeDebugInformationOn: serializer. > serializer addPostMaterializationAction: [ :materialization | > Smalltalk tools debugger > openOn: Processor activeProcess > context: materialization root > label: 'External stack' > contents: nil > fullView: false ]. > > So it looks like now it should create a debug session first and then pass it to the debugger? I think loading new fuel in Pharo3.x is still possible so maybe it is best to re-add that protocol? > > > Well, if the GT developers (CC'ed Dory) do not want to add back the old protocol, then no problem, we do have a way to manage portability across dialects and versions. Max Leske (CC'ed) has changed and improved this in the recent months. So I will wait to see if he can take care. Else, I will do it. > > Thanks for the report. > > > > -- > Mariano > http://marianopeck.wordpress.com <http://marianopeck.wordpress.com/>

Dec. 19, 2016

Re: [Pharo-users] DNU on materializing a fueled out exception

by Andrei Chis

Hi Holgen, This should be fixed by updating #serializeTestFailureContext:toFileNamed:. The API of the debugger was refactored in Pharo 5 and it seems like #serializeTestFailureContext:toFileNamed: was not updated in Pharo 5. Created an issue case 19477 <https://pharo.fogbugz.com/f/cases/19477/Fuel-out-Stack-uses-old-debugger-AP…>. Also currently on mac there is another issue when fueling out the stack (case 19064 <https://pharo.fogbugz.com/f/cases/19064/Fuel-out-stack-not-working>) Cheers, Andrei On Mon, Dec 19, 2016 at 9:53 AM, Holger Freyther <holger(a)freyther.de> wrote: > Hi, > > I showed Pharo to a friend and wanted to show the nice feature of fueling > out an exception and then using FLMaterializer class>>#materializeFromFileNamed: > to load it back and get a debugger up. In Pharo5 I am presented a DNU > instead. > > The DNU is on GTGenericStackDebugger as it doesn't understand the message > Fuel is sending. What to fix, Fuel to use the new protocol or > GTGenericStackDebugger to honor the old protocol? > > FueldOutStackDebugAction>>#serializeTestFailureContext: aContext > toFileNamed: aFilename > | serializer | > > serializer := FLSerializer newDefault. > self encodeDebugInformationOn: serializer. > serializer addPostMaterializationAction: [ :materialization | > Smalltalk tools debugger > openOn: Processor activeProcess > context: materialization root > label: 'External stack' > contents: nil > fullView: false ]. > > So it looks like now it should create a debug session first and then pass > it to the debugger? I think loading new fuel in Pharo3.x is still possible > so maybe it is best to re-add that protocol? > > comments? > > holger >

Dec. 19, 2016

Re: [Pharo-users] DNU on materializing a fueled out exception

by Mariano Martinez Peck

On Mon, Dec 19, 2016 at 4:53 AM, Holger Freyther <holger(a)freyther.de> wrote: > Hi, > > I showed Pharo to a friend and wanted to show the nice feature of fueling > out an exception and then using FLMaterializer class>>#materializeFromFileNamed: > to load it back and get a debugger up. In Pharo5 I am presented a DNU > instead. > > Hi Holger, I hope you were able to show that example to him anyways. That example make us won the first price at ESUG awards hahaha. I still remember when I was sitting at home, trying to think of a good example to show and I thought: "what if I serialize the debugger and the stack to another image?". I tried and it worked out of the box. One of the happiest dev programming days ever hahaha. The DNU is on GTGenericStackDebugger as it doesn't understand the message > Fuel is sending. What to fix, Fuel to use the new protocol or > GTGenericStackDebugger to honor the old protocol? > > FueldOutStackDebugAction>>#serializeTestFailureContext: aContext > toFileNamed: aFilename > | serializer | > > serializer := FLSerializer newDefault. > self encodeDebugInformationOn: serializer. > serializer addPostMaterializationAction: [ :materialization | > Smalltalk tools debugger > openOn: Processor activeProcess > context: materialization root > label: 'External stack' > contents: nil > fullView: false ]. > > So it looks like now it should create a debug session first and then pass > it to the debugger? I think loading new fuel in Pharo3.x is still possible > so maybe it is best to re-add that protocol? > > Well, if the GT developers (CC'ed Dory) do not want to add back the old protocol, then no problem, we do have a way to manage portability across dialects and versions. Max Leske (CC'ed) has changed and improved this in the recent months. So I will wait to see if he can take care. Else, I will do it. Thanks for the report. -- Mariano http://marianopeck.wordpress.com

Dec. 19, 2016

[ANN] TechTalks Jan and Feb

by Marcus Denker

Hi, We have fixed the next two tech talks: - 24 Jan 2017. Topic "Bloc/Brickâ https://association.pharo.org/event-2405619 - 28 Feb 2017. Topic: âRefelectivity" https://association.pharo.org/event-2407465 We added these as âEventsâ to the association website. People registered there will get the information how to participate via mail (and a mail pointing to the recording afterwards). This is therefor especially interesting for those not following the mailing lists. The idea is to have one each months, if you have ideas for topics (or want to do some yourself), send a mail. Blog post: http://pharo.org/news/techtalks17

Dec. 19, 2016

Re: [Pharo-users] Hash collision

by Andres Valloud

At first glance, that the failure code only sees "two" things when it should see "eight" seems to be problematic. Perhaps the primitive insists on hashing byte objects, and there is a distinction between "byte" objects and "word" objects (whatever "word" means, presumably a constant width integer across all platforms). I haven't looked at the code. From my perspective... back in the day that primitive used to hash bytes, and from what I saw here the failure code is hashing multi-byte things. If all of these observations are correct, then I'd say the failure code isn't doing what the primitive is doing, and in doing so it's introducing a lot of collisions that I'd like to believe the intended hash function wouldn't produce. Andres. On 12/18/16 23:05 , Martin McClure wrote: > On 12/18/2016 02:29 AM, Andres Valloud wrote: >> The primitive and the primitive failure code should behave the same? > > You think the primitive is faulty? I haven't looked at the primitive > code, but it just fails when given a Float. From the name, I'd guess > that it's designed for a byte object. The failure code certainly is. > > A new primitive designed for word objects, or new code such as I gave > earlier (though ugly) would work, though. > > Regards, > > -Martin >

Dec. 19, 2016

Re: [Pharo-users] iceberg and private github repos

by Tudor Girba

Hi, I had some troubles, that is why I asked :). But, I just tried again, and it looks like itâs working. Cheers, Doru > On Dec 19, 2016, at 9:54 AM, Nicolas Passerini <npasserini(a)gmail.com> wrote: > > Honestly I never tried, but I do not see why it wouldn't work. Please let me know if you find trouble. > > 2016-12-19 9:51 GMT+01:00 Esteban Lorenzano <estebanlm(a)gmail.com>: > I guess is about credentials: you have the right user/pass, you will not have problemsâ¦ but thatâs just an âI guessâ :) > > (remember: iceberg just works with https security right nowâ¦ due current limitations on libgit2, not our fault :P) > > Esteban > > > On 19 Dec 2016, at 09:26, Tudor Girba <tudor(a)tudorgirba.com> wrote: > > > > Hi, > > > > I have to work with a private GitHub repo. Is there a way to tell Iceberg to load from such a private repo? > > > > Cheers, > > Doru > > > > > > -- > > www.tudorgirba.com > > www.feenk.com > > > > "We cannot reach the flow of things unless we let go." > > > > > > > > > > > > > -- www.tudorgirba.com www.feenk.com "Every now and then stop and ask yourself if the war you're fighting is the right one."

Dec. 19, 2016

Re: [Pharo-users] iceberg and private github repos

by Nicolas Passerini

Honestly I never tried, but I do not see why it wouldn't work. Please let me know if you find trouble. 2016-12-19 9:51 GMT+01:00 Esteban Lorenzano <estebanlm(a)gmail.com>: > I guess is about credentials: you have the right user/pass, you will not > have problemsâ¦ but thatâs just an âI guessâ :) > > (remember: iceberg just works with https security right nowâ¦ due current > limitations on libgit2, not our fault :P) > > Esteban > > > On 19 Dec 2016, at 09:26, Tudor Girba <tudor(a)tudorgirba.com> wrote: > > > > Hi, > > > > I have to work with a private GitHub repo. Is there a way to tell > Iceberg to load from such a private repo? > > > > Cheers, > > Doru > > > > > > -- > > www.tudorgirba.com > > www.feenk.com > > > > "We cannot reach the flow of things unless we let go." > > > > > > > > > > > > >

Dec. 19, 2016