Indeed, please let’s focus on Pharo issues on this mailing list.
Cheers,
Doru
> On Dec 20, 2016, at 1:25 AM, Travis Ayres wrote:
>
> Totally agreed.
>
> On Mon, Dec 19, 2016 at 4:17 PM, Brad wrote:
> Don't know about anyone else, but I would
Ah, it seems I just did not switched it on - it does not work after all.
I tried it with PasswordHashingFFI-PaulDeBrulcker.16.mcz, but also with 15
and 8.
On Pharo 5, it calls many methods which I do not have in my environment, for
example in BCryptLinuxFFI>>#generateBCryptSalt: there is line
Hello,
I need help rescuing code that has dependencies on FFI. I just downloaded
the latest Pharo 5 vm in order to run Pharo under MacOS 10.12. Now the
FFI-based code in my image no longer works (or is viewable).
What worked before (for years, up through MacOS 10.11) is as follows:
I have
Consider words from the street. All those potential Pharo users!
https://www.youtube.com/watch?v=jMnLHmTXjgU=PLJiUTrmz_5UMkFsdjCRJD0bpRpuswwccx=1
On 12/19/2016 8:11 PM, Charlie Robbats wrote:
This is how I deal with ptsd. Change the system.
On 12/19/2016 8:08 PM, Charlie Robbats wrote:
Totally agreed.
On Mon, Dec 19, 2016 at 4:17 PM, Brad wrote:
> Don't know about anyone else, but I would appreciate it if this kind of
> commentary never made it to this email list. This topic is so
> inappropriate. Let's keep the discussion about Pharo. If you feel you
Don't know about anyone else, but I would appreciate it if this kind of
commentary never made it to this email list. This topic is so inappropriate.
Let's keep the discussion about Pharo. If you feel you must go down the
political route, then please be gracious enough to find another venue.
Thank you a lot! :)
I tried it in Pharo 5 and everything seems to be working (I just had to
apt-get install libxcrypt:i386, load packages Cryptography, Blowfish (not
sure if really needed though) and PasswordHashingFFI and manually create
link in directory where it expected libxcrypt.so.1). About
On 12/19/2016 01:27 AM, Andres Valloud wrote:
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
And to add scrypt to that FFI library would be trivial if you have a 32bit
version of scrypt but I don't think there is one. I'd be happy to learn I'm
wrong though. And thats assuming you're using 32 bit pharo, which is whats
stable/released right now.
Paul DeBruicker wrote
> I made a
I made a crypt/bcrypt ffi library for older versions of Pharo that sounds
like it meets your needs and is in the cryptography project here:
http://smalltalkhub.com/#!/~Cryptography/Cryptography
But I have not updated it for the new FFI versions in Pharo 5/6.
And Pierce Ng made a blog post
>I require at least bcrypt or PDKBF2, but I much more prefer
>GPU-attack-resistant solutions like scrypt or Argon2.
If required you can use external libraries like scrypt
(https://lolware.net/2014/04/29/libscrypt.html)
and call it using UFFI from Pharo
Thanks
T.
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
Hi,
> On Dec 19, 2016, at 6:34 PM, Denis Kudriashov wrote:
>
> Hi.
>
> 2016-12-19 18:08 GMT+01:00 Max Leske :
> I suppose that functionality should be resolved via FuelPlatform. Something
> like
>
> FLPlatform current
> openDebuggerOn:
2016-12-19 18:34 GMT+01:00 Denis Kudriashov :
> 016-12-19 18:08 GMT+01:00 Max Leske :
>
>> I suppose that functionality should be resolved via FuelPlatform.
>> Something like
>>
>> FLPlatform current
>> openDebuggerOn: Processor activeProcess
>> context:
Hi.
2016-12-19 18:08 GMT+01:00 Max Leske :
> 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
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.
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
On Mon, Dec 19, 2016 at 4:53 AM, Holger Freyther 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
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
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 wrote:
>
> Honestly I never tried, but I do not see why it wouldn't work. Please let me
> know if
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 :
> I guess is about credentials: you have the right user/pass, you will not
> have problems… but that’s just an “I guess” :)
>
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."
22 matches
Mail list logo