July 2014 - Pharo-users - lists.pharo.org

Re: [Pharo-users] Should I be reporting bugs in Pharo 3.0?

by Tim Mackinnon

Hi Nicolai - I should have added that I like the direction that Nautilus is going (and it looks cool) - there is a lot of potential particularly if the code underneath is clean (my experience with the browser code from Squeak, was that it was messy - and seemed to have been ported through several systems). I have reported several bugs which I'm assuming you have seen. I think the problems surface more when something is new and you play around with it to understand what things do. I particularly like to understand the inheritance hierarchy of things I'm looking at - hence why I click those buttons. Tim -- View this message in context: http://forum.world.st/Should-I-be-reporting-bugs-in-Pharo-3-0-tp4767284p476… Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.

July 10, 2014

Re: [Pharo-users] Should I be reporting bugs in Pharo 3.0?

by Nicolai Hess

2014-07-09 22:51 GMT+02:00 Tim Mackinnon <tamackinnon(a)gmail.com>: > OK - will do. > > I am finding that Nautilus in Pharo 3 is very flakey - its very easy to get > into a position where you cant select anything in the package or class pane > - and you just get walkbacks making it unusable. I'm surprised its not been > noticed already. > > Tim > I am working on that :) Every bug report is helpfull. My observation is, most people have a worklfow that does not provoke this issues or accustomed to work around it. My goal is to have a solid systembrowser. I want to clean and simplify nautilus group/package handling, the caches and the way it updates on system messages (classdef. change, methods add/removed ...) Nicolai > > > > -- > View this message in context: > http://forum.world.st/Should-I-be-reporting-bugs-in-Pharo-3-0-tp4767284p476… > Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com. > >

July 10, 2014

Re: [Pharo-users] Should I be reporting bugs in Pharo 3.0?

by Esteban Lorenzano

On 10 Jul 2014, at 08:52, Marcus Denker <marcus.denker(a)inria.fr> wrote: > > On 09 Jul 2014, at 23:08, Tim Mackinnon <tamackinnon(a)gmail.com> wrote: > >> Just to clarify - should I just submit for 4.0 and make a note that it >> applies to 3.0 and then you guys can make a duplicate? >> >> Or should I make a duplicate? If its me - how do I duplicate a bug in >> fogbugz - I can't see an option to do it (and would expect it to link the >> two) >> > > We just make a new report and put the Pharo4 report as the *child* of the Pharo3 one, > so that it will be tested first in Pharo4 of course, in case we find that the bugfix deserves to be backported (is an important fix) otherwise, the fix will be there just in pharo4 :) Esteban > > Marcus > >

July 10, 2014

Re: [Pharo-users] Using FFI

by Esteban Lorenzano

On 10 Jul 2014, at 02:32, Andres Valloud <avalloud(a)smalltalk.comcastbiz.net> wrote: > On 64 bit Windows a long is 32 bits and pointers are 64 bits, so that type of replacement is not going to work in the long runâ¦ Of course, but letâs take care about that problem when actually become a problem :) Hopefully, for when we finally have a 64bits with FFI, we will have a proper ** interpretation, but the workaround is the fastest solution you can have for now. Esteban > > On 7/9/14 8:20 , Esteban Lorenzano wrote: >> yes, FFI does not handle ** arguments. >> I always replace it by ulong instead (it is the same, after all) >> >> Esteban >> >> On 09 Jul 2014, at 17:17, ClÃ©ment Bera <bera.clement(a)gmail.com >> <mailto:bera.clement@gmail.com>> wrote: >> >>> Hello, >>> >>> This bug happen both with the old and new compiler. >>> >>> The error tells you that the number of arguments of your smalltalk >>> method does not match the number of argument of the C method you want >>> to call (but it seemsthe number of arguments is correct). >>> >>> This works fine: >>> >>> <apicall: int 'gst_init_check' (int char* int) module: >>> 'libgstreamer1.0-0.so <http://libgstreamer1.0-0.so/>'> >>> ^self externalCallFailed >>> >>> This works fine too: >>> >>> <apicall: int 'gst_init_check' (int* char* int*) module: >>> 'libgstreamer1.0-0.so <http://libgstreamer1.0-0.so/>'> >>> ^self externalCallFailed >>> >>> So it seems the bug comes from the parser missparsing ** . I am not >>> familiar with C enough to help, I don't know what means ** (Is it a >>> pointer pointing to a pointer pointing to the actual data ?). >>> >>> Perhaps someone who knows how to use FFI can give a better answer. >>> >>> Esteban ? Guille ? >>> >>> >>> 2014-07-09 16:39 GMT+02:00 Annick Fron <info(a)afceurope.com >>> <mailto:info@afceurope.com>>: >>> >>> >>> Hi, >>> >>> >>> >>> I am trying to use FFI on linux with pharo 3 using version >>> 31 of FFI. >>> >>> I have written the following method : >>> >>> >>> <apicall: int 'gst_init_check' (int* char** int*) module: >>> 'libgstreamer1.0-0.so <http://libgstreamer1.0-0.so/>'> >>> >>> ^self externalCallFailed >>> >>> >>> ==== >>> >>> but when accepting it I get a syntax error Â« matching number of >>> arguments Â» >>> Annick Fron >>> >>> >> >

July 10, 2014

Re: [Pharo-users] [Blog] PBKDF2 for Pharo

by Sven Van Caekenberghe

Udo, On 10 Jul 2014, at 10:44, Udo Schneider <Udo.Schneider(a)homeaddress.de> wrote: > > About this larger project was it developed in Pharo? > It /is/ still developed - and it's Pharo all the way down. I removed the last non-Pharo component (stunnel) last week when I succeeded in combining the existing LDAP bindings with Zodiac (SSL was a must due to AD integration). Nice. > > Because we are looking for success stories. > I can check. The project is an internal-only webapp at the moment. > > It basically a "simple" Seaside, Magritte, Bootstrap and SandstoneDB WebApp at first sight. Behind the scenes there are some integration points with REST Services and AD (thus the need for LDAP(S)) going on. A success story is an application using Pharo that makes a real difference, that adds value in the (commercial) world. Enterprise software is all about integrations, it is never really "simple" ;-) I wish you a successful continuation of the project ! Sven > Best Regards. > > Udo > > > > > On 10.07.2014 09:41, stepharo wrote: >> super >> >> Thalnks for sharing that with us. >> >> About this larger project was it developed in Pharo? Because we are >> looking for success stories. >> >> Stef >> >> On 10/7/14 09:00, Udo Schneider wrote: >>> I just extracted some PBKDF2 code from a bigger project. So if you >>> want to derive keys from an non-optimal source (e.g. user input) or >>> store non-reversible passwords with (tunable) secure salting/hashing >>> then PBKDF2 is your friend. >>> >>> The blog is here: >>> http://readthesourceluke.blogspot.de/2014/07/pbkdf2-for-pharo.html >>> >>> The source is on SH: >>> http://smalltalkhub.com/#!/~udos/PBKDF2 >>> >>> Have fun! >>> >>> CU, >>> >>> Udo >>> >>> >>> >> >> >> > > >

July 10, 2014

Re: [Pharo-users] [Blog] PBKDF2 for Pharo

by Udo Schneider

> About this larger project was it developed in Pharo? It /is/ still developed - and it's Pharo all the way down. I removed the last non-Pharo component (stunnel) last week when I succeeded in combining the existing LDAP bindings with Zodiac (SSL was a must due to AD integration). > Because we are looking for success stories. I can check. The project is an internal-only webapp at the moment. It basically a "simple" Seaside, Magritte, Bootstrap and SandstoneDB WebApp at first sight. Behind the scenes there are some integration points with REST Services and AD (thus the need for LDAP(S)) going on. Best Regards. Udo On 10.07.2014 09:41, stepharo wrote: > super > > Thalnks for sharing that with us. > > About this larger project was it developed in Pharo? Because we are > looking for success stories. > > Stef > > On 10/7/14 09:00, Udo Schneider wrote: >> I just extracted some PBKDF2 code from a bigger project. So if you >> want to derive keys from an non-optimal source (e.g. user input) or >> store non-reversible passwords with (tunable) secure salting/hashing >> then PBKDF2 is your friend. >> >> The blog is here: >> http://readthesourceluke.blogspot.de/2014/07/pbkdf2-for-pharo.html >> >> The source is on SH: >> http://smalltalkhub.com/#!/~udos/PBKDF2 >> >> Have fun! >> >> CU, >> >> Udo >> >> >> > > >

July 10, 2014

Re: [Pharo-users] [Blog] PBKDF2 for Pharo

by stepharo

super Thalnks for sharing that with us. About this larger project was it developed in Pharo? Because we are looking for success stories. Stef On 10/7/14 09:00, Udo Schneider wrote: > I just extracted some PBKDF2 code from a bigger project. So if you > want to derive keys from an non-optimal source (e.g. user input) or > store non-reversible passwords with (tunable) secure salting/hashing > then PBKDF2 is your friend. > > The blog is here: > http://readthesourceluke.blogspot.de/2014/07/pbkdf2-for-pharo.html > > The source is on SH: > http://smalltalkhub.com/#!/~udos/PBKDF2 > > Have fun! > > CU, > > Udo > > >

July 10, 2014

[Blog] PBKDF2 for Pharo

by Udo Schneider

I just extracted some PBKDF2 code from a bigger project. So if you want to derive keys from an non-optimal source (e.g. user input) or store non-reversible passwords with (tunable) secure salting/hashing then PBKDF2 is your friend. The blog is here: http://readthesourceluke.blogspot.de/2014/07/pbkdf2-for-pharo.html The source is on SH: http://smalltalkhub.com/#!/~udos/PBKDF2 Have fun! CU, Udo

July 10, 2014

Re: [Pharo-users] Should I be reporting bugs in Pharo 3.0?

by Marcus Denker

On 09 Jul 2014, at 23:08, Tim Mackinnon <tamackinnon(a)gmail.com> wrote: > Just to clarify - should I just submit for 4.0 and make a note that it > applies to 3.0 and then you guys can make a duplicate? > > Or should I make a duplicate? If its me - how do I duplicate a bug in > fogbugz - I can't see an option to do it (and would expect it to link the > two) > We just make a new report and put the Pharo4 report as the *child* of the Pharo3 one, so that it will be tested first in Pharo4 Marcus

July 10, 2014

Re: [Pharo-users] Using FFI

by Andres Valloud

On 64 bit Windows a long is 32 bits and pointers are 64 bits, so that type of replacement is not going to work in the long run... On 7/9/14 8:20 , Esteban Lorenzano wrote: > yes, FFI does not handle ** arguments. > I always replace it by ulong instead (it is the same, after all) > > Esteban > > On 09 Jul 2014, at 17:17, ClÃ©ment Bera <bera.clement(a)gmail.com > <mailto:bera.clement@gmail.com>> wrote: > >> Hello, >> >> This bug happen both with the old and new compiler. >> >> The error tells you that the number of arguments of your smalltalk >> method does not match the number of argument of the C method you want >> to call (but it seemsthe number of arguments is correct). >> >> This works fine: >> >> <apicall: int 'gst_init_check' (int char* int) module: >> 'libgstreamer1.0-0.so <http://libgstreamer1.0-0.so/>'> >> ^self externalCallFailed >> >> This works fine too: >> >> <apicall: int 'gst_init_check' (int* char* int*) module: >> 'libgstreamer1.0-0.so <http://libgstreamer1.0-0.so/>'> >> ^self externalCallFailed >> >> So it seems the bug comes from the parser missparsing ** . I am not >> familiar with C enough to help, I don't know what means ** (Is it a >> pointer pointing to a pointer pointing to the actual data ?). >> >> Perhaps someone who knows how to use FFI can give a better answer. >> >> Esteban ? Guille ? >> >> >> 2014-07-09 16:39 GMT+02:00 Annick Fron <info(a)afceurope.com >> <mailto:info@afceurope.com>>: >> >> >> Hi, >> >> >> >> I am trying to use FFI on linux with pharo 3 using version >> 31 of FFI. >> >> I have written the following method : >> >> >> <apicall: int 'gst_init_check' (int* char** int*) module: >> 'libgstreamer1.0-0.so <http://libgstreamer1.0-0.so/>'> >> >> ^self externalCallFailed >> >> >> ==== >> >> but when accepting it I get a syntax error Â« matching number of >> arguments Â» >> Annick Fron >> >> >

July 10, 2014