Re: [Pharo-dev] Big claps for Epicea (small request!)

[Mariano Martinez Peck]

On Wed, Jul 19, 2017 at 6:16 PM, Nicolas Cellier <
nicolas.cellier.aka.n...@gmail.com> wrote:

> format before diff is in the top 5 of my most hated default.
> As an author, I try to write short methods and adhere to a standard format
> (Kent Beck like).
>
> But I want the freedom to use derogation when the format helps
> comprehension.
> If I did the effort of using a special formatting, the last thing that I
> want is a "smart" tool that undo my work.
> The best time to format code is when we accept it, and only if there is a
> quick way to undo/bypass if we don't like it.
>
> The formatter is dumb.
> Let's illustrate it with literals among other things.
>
> I might want to write 16rBADA55, but I'm sure i never want to read
> 12245589, it makes no sense ;)
> (hey, this is a real example you can find in VMMaker sources, not just the
> production of my ill brain).
>
> And if I make an effort to format a character encoding table on several
> lines to have it readable
>#(
>   line1
>   line2
>   ...
>   lineN ).
> I'm pretty sure I never want to diff a single line with about 1024
> columns...
>
> So please make this an option (with a default to false)!
>
>

Hi Nicolas,

Yes, in all the rest of Pharo it is an option (a checkbox on the top right)
and it is false by default.

Cheers,


> 2017-07-19 22:27 GMT+02:00 Mariano Martinez Peck :
>
>> Hi Martin,
>>
>> Thank you VERY MUCH for Epicea. I just had a crash and it was way more
>> comfortable to recover changes.
>>
>> One small request would be to allow "Pretty Print" in the diff to the
>> changes to be applied. Many times I changed formatting etc so for when
>> viewing changes, viewing with same formatting helps me to see the actual
>> changes and not formatting changes.
>>
>> Thanks!
>>
>> --
>> Mariano
>> http://marianopeck.wordpress.com
>>
>
>


-- 
Mariano
http://marianopeck.wordpress.com

Re: [Pharo-dev] Big claps for Epicea (small request!)

[Nicolas Cellier]

format before diff is in the top 5 of my most hated default.
As an author, I try to write short methods and adhere to a standard format
(Kent Beck like).

But I want the freedom to use derogation when the format helps
comprehension.
If I did the effort of using a special formatting, the last thing that I
want is a "smart" tool that undo my work.
The best time to format code is when we accept it, and only if there is a
quick way to undo/bypass if we don't like it.

The formatter is dumb.
Let's illustrate it with literals among other things.

I might want to write 16rBADA55, but I'm sure i never want to read
12245589, it makes no sense ;)
(hey, this is a real example you can find in VMMaker sources, not just the
production of my ill brain).

And if I make an effort to format a character encoding table on several
lines to have it readable
   #(
  line1
  line2
  ...
  lineN ).
I'm pretty sure I never want to diff a single line with about 1024
columns...

So please make this an option (with a default to false)!

2017-07-19 22:27 GMT+02:00 Mariano Martinez Peck :

> Hi Martin,
>
> Thank you VERY MUCH for Epicea. I just had a crash and it was way more
> comfortable to recover changes.
>
> One small request would be to allow "Pretty Print" in the diff to the
> changes to be applied. Many times I changed formatting etc so for when
> viewing changes, viewing with same formatting helps me to see the actual
> changes and not formatting changes.
>
> Thanks!
>
> --
> Mariano
> http://marianopeck.wordpress.com
>

[Pharo-dev] Big claps for Epicea (small request!)

[Mariano Martinez Peck]

Hi Martin,

Thank you VERY MUCH for Epicea. I just had a crash and it was way more
comfortable to recover changes.

One small request would be to allow "Pretty Print" in the diff to the
changes to be applied. Many times I changed formatting etc so for when
viewing changes, viewing with same formatting helps me to see the actual
changes and not formatting changes.

Thanks!

-- 
Mariano
http://marianopeck.wordpress.com

Re: [Pharo-dev] [Ann] Keccak hashing algorithm

[Stephane Ducasse]

Thanks Norbert. The consortium paid nicolas to deliver iceberg and
esteban to push further for git because
the world is moving and git and github support will give us a lot of
exposure and a really powerful distributing versionning source control
system (even if I really enjoyed MC - it is showing its age - I will
be also happy when Smalltalkhub will be a nice legacy not getting in
my way. For the record people close to me know that I do not like git
even if I like its underlying social model - fork and we pushed git
not by accident. But to sustain business and our community.

I often have the impression that we are ants fighting together while
elephants (python, ruby, JS) are running around. I spent a lot of time
pushing Squeak in the past - I'm basically the guy that wrote most
books and produced a lot of teaching material on Squeak, but I arrived
to a point where I decided that there were no reasonance about the
vision (innovation and business) I wanted for a new generation
smalltalk so I decided that Squeak was ok for me and that all my
energy is for Pharo.
I do not like to compete to runner competition with snowshoes while
others have supercool nike and this "let us do something compatible"
like forcing me to wear snow shoes. I paid attention to avoid non
backward compatible changes but after a while what should be done
should be done.
I think that since 2008 we show that we value: community building,
business support and delivering an excellent system.

So I'm like you, if everything I do should be compatible with Squeak
and others then I should better go and do fun stuff in Lua, Python,
Ruby or JS.
People may think that it is sad or that I'm arrogant asshole: I do not
care because this is my fun and my life.
Pharo is open and people are welcome to build it with us. We are
always really open to co-build it but it also means taking
responsibility.

So thanks for sharing the vision with us.

Stef


On Wed, Jul 19, 2017 at 1:39 PM, Norbert Hartl  wrote:
> Eliot,
>
> Am 18.07.2017 um 22:26 schrieb Eliot Miranda :
>
> Norbert,
>
> On Tue, Jul 18, 2017 at 11:05 AM, Norbert Hartl  wrote:
>>
>> Really great! I think we should move the Cryptography package from
>> smalltalkhub to github, refactor it and add goodies like this. We need a
>> strong crypto foundation.
>
>
> I agree that refactoring and adding goodies is great.  But why does that
> imply moving to github?  The Cryptography package has Squeak contributors
> too and moving to github implies a fork.
>
>
> That fork happened already because there is a repository on smalltalkhub
> [1]. Lately I needed crypto support for a project of mine and I was
> searching for the last thing I could use. I was glad I've found the package
> Esteban did so I could use it in pharo. But I didn't know it was only the
> very last version that worked on pharo. But my Metacello setup somehow
> decided to load the second recent package which rendered my image unusable.
> From then I know that there are a lot of classes that have been incorporated
> in pharo which are present in the Cryptography package. I was asking for
> someone that maintains it and got no response.
> It is clear to me that there is no easy way to maintain the package for both
> squeak and pharo. At least not while having one big package to share. It
> would need a bit of engineering. Then I remembered I was asking a similar
> question (about splitting the Cryptography package) years ago and I didn't
> get much positive resonance. Btw. this was my general feeling with the
> squeak community back then and the same reason I was one of the first being
> on the pharo train (sapphire back then).
> To make a long story short. I really like spending some time for the
> smalltalk community. And I'm afraid I could kill my time and my mood while
> trying to get an agreement for something both squeak and pharo. So my
> current strategy is to care less and look (selfishly) forward. Maybe the
> better way is that each side has a look at the repository of the others and
> merges what is needed.
> Why github? Because I want a reliable repository where my business process
> runs on. Smalltalkhub is close to its final growth. And my impression is
> that if we would put the load from smalltalkhub onto squeaksource the only
> thing we would notice is a bright flash and silence after.
> Furthermore after all those years it turns out that you have a hard time of
> you do version your stuff and you want versioning to work reliable. What
> really works for me is having a github repo, a BaselineOf my project and
> tags on commits. Anything else just does not work and/or is not
> reproducible.
>
> Norbert
>
> [1] http://smalltalkhub.com/#!/~Cryptography/Cryptography
>>
>>
>> Norbert
>>
>> > Am 18.07.2017 um 19:10 schrieb Esteban A. Maringolo
>> > :
>> >
>> > Great!
>> >
>> > I see you continue doing Ethereum related stuff ;-)
>> >
>> > Regards!

Re: [Pharo-dev] OSProcess error with Linux 64-bit VM

[Alistair Grant]

Hi Thierry,

On Wed, Jul 19, 2017 at 04:01:46PM +0200, Thierry Goubier wrote:
> Hi Alistair,
> 
> OSProcess use of ifNotNilDo: will simply get rewritten on the fly when you 
> load
> it via Metacello.

This doesn't work in Pharo 7 because the methods are no longer present
(thus the re-write rule isn't present).

Cheers,
Alistair



> Thierry
> 
> 2017-07-19 15:56 GMT+02:00 Alistair Grant :
> 
> Hi Luke,
> 
> On Wed, Jul 19, 2017 at 02:25:55PM +0200, Luke Gorrie wrote:
> > Hoi,
> >
> > Does OSProcess work for other people with a 64-bit Linux VM?
> >
> > I am seeing strange errors specifically when I build in 64-bit mode:
> Processes
> > always immediately print an obscure error and exit with status 127.
> >
> > The error is printed by the child process. It seems to contain some
> control
> > characters, or a funky text encoding, and a large number for its error
> code.
> >
> > [pid 19070] writev(2, [{"/bin/sh", 7}, {": ", 2}, {" \n\2303\374\177",
> 6}, {":
> > ", 2}, {"", 0}, {"", 0}, {"\270\271\247\336;\177", 6}, {": ", 2}, 
> {"Error
> > 18446744073136382760", 26},\
> >  {"\n", 1}], 10) = 52
> >
> > More complete strace output in this gist: https://gist.github.com/
> > 81ca7b1c6b8cc412b66951bb6d57e1ea
> >
> > Reproduce with e.g. OSProcess command: 'pwd' (it doesn't seem to matter
> what
> > command is chosen.)
> >
> > Anybody else see this / not see this? Any ideas?
> >
> > Could be that some of the magic in the UnixOSProcessPlugin fork method 
> is
> not
> > working on 64-bit or with my toolchain...?
> 
> I wanted to try and reproduce this with my locally built VM but can't
> even load OSProcess because it is using the deprecated message
> #ifNotNilDo:.
> 
> I'm currently loading OSProcess using:
> 
> Metacello new
> configuration: 'OSProcess';
> version: #stable;
> repository: 'http://smalltalkhub.com/mc/Pharo/MetaRepoForPharo50/
> main';
> load.
> 
> 
> Would you please let me know how you load OSProcess?
> 
> Thanks,
> Alistair

Re: [Pharo-dev] OSProcess error with Linux 64-bit VM

[Alistair Grant]

Hi Luke,

On Wed, Jul 19, 2017 at 03:58:59PM +0200, Luke Gorrie wrote:
> Hi Alistair,
> 
> I'm loading via the Gofer commands that I found here:
> http://pharo.gemtalksystems.com/book/PharoTools/OSProcess/
> 
> Is that what fails for you?

Loading it in to Pharo 6 instead of Pharo 7 works :-)

I'm not seeing the problems you mention below (using my locally built
VM):

$ pharo --version
5.0-201705310241  Mon Jun 12 17:15:39 CEST 2017 gcc 4.8.5 [Production Spur 
64-bit VM]
CoInterpreter VMMaker.oscog-eem.2231 uuid: de62947a-7f40-4977-a232-e06a3a80c939 
Jun 12 2017
StackToRegisterMappingCogit VMMaker.oscog-eem.2227 uuid: 
7ea146b4-39ce-4de7-afa3-a76ed1d1da35 Jun 12 2017
VM: 201705310241 
alistair@alistair-xps13:snap/pharo-snap/pharo-vm/opensmalltalk-vm $ Date: Tue 
May 30 19:41:27 2017 -0700 $
Plugins: 201705310241 
alistair@alistair-xps13:snap/pharo-snap/pharo-vm/opensmalltalk-vm $
Linux 95f17752871f 4.8.0-52-generic #55~16.04.1-Ubuntu SMP Fri Apr 28 14:36:29 
UTC 2017 x86_64 x86_64 x86_64 GNU/Linux
plugin path: /snap/pharo/9/usr/bin/pharo-vm/5.0-201705310241 [default: 
/snap/pharo/9/usr/bin/pharo-vm/5.0-201705310241/]


Thierry, thanks for letting me know about the re-write, I'll look in to
that next.


Cheers,
Alistair



> On 19 July 2017 at 15:56, Alistair Grant  wrote:
> 
> Hi Luke,
> 
> On Wed, Jul 19, 2017 at 02:25:55PM +0200, Luke Gorrie wrote:
> > Hoi,
> >
> > Does OSProcess work for other people with a 64-bit Linux VM?
> >
> > I am seeing strange errors specifically when I build in 64-bit mode:
> Processes
> > always immediately print an obscure error and exit with status 127.
> >
> > The error is printed by the child process. It seems to contain some
> control
> > characters, or a funky text encoding, and a large number for its error
> code.
> >
> > [pid 19070] writev(2, [{"/bin/sh", 7}, {": ", 2}, {" \n\2303\374\177",
> 6}, {":
> > ", 2}, {"", 0}, {"", 0}, {"\270\271\247\336;\177", 6}, {": ", 2}, 
> {"Error
> > 18446744073136382760", 26},\
> >  {"\n", 1}], 10) = 52
> >
> > More complete strace output in this gist: https://gist.github.com/
> > 81ca7b1c6b8cc412b66951bb6d57e1ea
> >
> > Reproduce with e.g. OSProcess command: 'pwd' (it doesn't seem to matter
> what
> > command is chosen.)
> >
> > Anybody else see this / not see this? Any ideas?
> >
> > Could be that some of the magic in the UnixOSProcessPlugin fork method 
> is
> not
> > working on 64-bit or with my toolchain...?
> 
> I wanted to try and reproduce this with my locally built VM but can't
> even load OSProcess because it is using the deprecated message
> #ifNotNilDo:.
> 
> I'm currently loading OSProcess using:
> 
> Metacello new
> configuration: 'OSProcess';
> version: #stable;
> repository: 'http://smalltalkhub.com/mc/Pharo/MetaRepoForPharo50/
> main';
> load.
> 
> 
> Would you please let me know how you load OSProcess?
> 
> Thanks,
> Alistair

Re: [Pharo-dev] OSProcess error with Linux 64-bit VM

[Thierry Goubier]

Hi Alistair,

OSProcess use of ifNotNilDo: will simply get rewritten on the fly when you
load it via Metacello.

Thierry

2017-07-19 15:56 GMT+02:00 Alistair Grant :

> Hi Luke,
>
> On Wed, Jul 19, 2017 at 02:25:55PM +0200, Luke Gorrie wrote:
> > Hoi,
> >
> > Does OSProcess work for other people with a 64-bit Linux VM?
> >
> > I am seeing strange errors specifically when I build in 64-bit mode:
> Processes
> > always immediately print an obscure error and exit with status 127.
> >
> > The error is printed by the child process. It seems to contain some
> control
> > characters, or a funky text encoding, and a large number for its error
> code.
> >
> > [pid 19070] writev(2, [{"/bin/sh", 7}, {": ", 2}, {" \n\2303\374\177",
> 6}, {":
> > ", 2}, {"", 0}, {"", 0}, {"\270\271\247\336;\177", 6}, {": ", 2}, {"Error
> > 18446744073136382760", 26},\
> >  {"\n", 1}], 10) = 52
> >
> > More complete strace output in this gist: https://gist.github.com/
> > 81ca7b1c6b8cc412b66951bb6d57e1ea
> >
> > Reproduce with e.g. OSProcess command: 'pwd' (it doesn't seem to matter
> what
> > command is chosen.)
> >
> > Anybody else see this / not see this? Any ideas?
> >
> > Could be that some of the magic in the UnixOSProcessPlugin fork method
> is not
> > working on 64-bit or with my toolchain...?
>
> I wanted to try and reproduce this with my locally built VM but can't
> even load OSProcess because it is using the deprecated message
> #ifNotNilDo:.
>
> I'm currently loading OSProcess using:
>
> Metacello new
> configuration: 'OSProcess';
> version: #stable;
> repository: 'http://smalltalkhub.com/mc/
> Pharo/MetaRepoForPharo50/main';
> load.
>
>
> Would you please let me know how you load OSProcess?
>
> Thanks,
> Alistair
>
>
>

Re: [Pharo-dev] OSProcess error with Linux 64-bit VM

[Luke Gorrie]

Hi Alistair,

I'm loading via the Gofer commands that I found here:
http://pharo.gemtalksystems.com/book/PharoTools/OSProcess/

Is that what fails for you?

On 19 July 2017 at 15:56, Alistair Grant  wrote:

> Hi Luke,
>
> On Wed, Jul 19, 2017 at 02:25:55PM +0200, Luke Gorrie wrote:
> > Hoi,
> >
> > Does OSProcess work for other people with a 64-bit Linux VM?
> >
> > I am seeing strange errors specifically when I build in 64-bit mode:
> Processes
> > always immediately print an obscure error and exit with status 127.
> >
> > The error is printed by the child process. It seems to contain some
> control
> > characters, or a funky text encoding, and a large number for its error
> code.
> >
> > [pid 19070] writev(2, [{"/bin/sh", 7}, {": ", 2}, {" \n\2303\374\177",
> 6}, {":
> > ", 2}, {"", 0}, {"", 0}, {"\270\271\247\336;\177", 6}, {": ", 2}, {"Error
> > 18446744073136382760", 26},\
> >  {"\n", 1}], 10) = 52
> >
> > More complete strace output in this gist: https://gist.github.com/
> > 81ca7b1c6b8cc412b66951bb6d57e1ea
> >
> > Reproduce with e.g. OSProcess command: 'pwd' (it doesn't seem to matter
> what
> > command is chosen.)
> >
> > Anybody else see this / not see this? Any ideas?
> >
> > Could be that some of the magic in the UnixOSProcessPlugin fork method
> is not
> > working on 64-bit or with my toolchain...?
>
> I wanted to try and reproduce this with my locally built VM but can't
> even load OSProcess because it is using the deprecated message
> #ifNotNilDo:.
>
> I'm currently loading OSProcess using:
>
> Metacello new
> configuration: 'OSProcess';
> version: #stable;
> repository: 'http://smalltalkhub.com/mc/
> Pharo/MetaRepoForPharo50/main';
> load.
>
>
> Would you please let me know how you load OSProcess?
>
> Thanks,
> Alistair
>
>
>

Re: [Pharo-dev] OSProcess error with Linux 64-bit VM

[Alistair Grant]

Hi Luke,

On Wed, Jul 19, 2017 at 02:25:55PM +0200, Luke Gorrie wrote:
> Hoi,
> 
> Does OSProcess work for other people with a 64-bit Linux VM?
> 
> I am seeing strange errors specifically when I build in 64-bit mode: Processes
> always immediately print an obscure error and exit with status 127.
> 
> The error is printed by the child process. It seems to contain some control
> characters, or a funky text encoding, and a large number for its error code.
> 
> [pid 19070] writev(2, [{"/bin/sh", 7}, {": ", 2}, {" \n\2303\374\177", 6}, {":
> ", 2}, {"", 0}, {"", 0}, {"\270\271\247\336;\177", 6}, {": ", 2}, {"Error
> 18446744073136382760", 26},\
>  {"\n", 1}], 10) = 52
> 
> More complete strace output in this gist: https://gist.github.com/
> 81ca7b1c6b8cc412b66951bb6d57e1ea
> 
> Reproduce with e.g. OSProcess command: 'pwd' (it doesn't seem to matter what
> command is chosen.)
> 
> Anybody else see this / not see this? Any ideas?
> 
> Could be that some of the magic in the UnixOSProcessPlugin fork method is not
> working on 64-bit or with my toolchain...?

I wanted to try and reproduce this with my locally built VM but can't
even load OSProcess because it is using the deprecated message
#ifNotNilDo:.

I'm currently loading OSProcess using:

Metacello new
configuration: 'OSProcess';
version: #stable;
repository: 'http://smalltalkhub.com/mc/Pharo/MetaRepoForPharo50/main';
load.


Would you please let me know how you load OSProcess?

Thanks,
Alistair

Re: [Pharo-dev] OSProcess error with Linux 64-bit VM

[Luke Gorrie]

Thanks for that data point, Thierry!

On 19 July 2017 at 14:29, Thierry Goubier  wrote:

> Hi Luke,
>
> I'm using OSProcess for my day to day development work in 64bits on the
> snap and default pharo vms, and it works.
>
> Regards,
>
> Thierry
>
>
> 2017-07-19 14:25 GMT+02:00 Luke Gorrie :
>
>> Hoi,
>>
>> Does OSProcess work for other people with a 64-bit Linux VM?
>>
>> I am seeing strange errors specifically when I build in 64-bit mode:
>> Processes always immediately print an obscure error and exit with status
>> 127.
>>
>> The error is printed by the child process. It seems to contain some
>> control characters, or a funky text encoding, and a large number for its
>> error code.
>>
>> [pid 19070] writev(2, [{"/bin/sh", 7}, {": ", 2}, {" \n\2303\374\177",
>> 6}, {": ", 2}, {"", 0}, {"", 0}, {"\270\271\247\336;\177", 6}, {": ", 2},
>> {"Error 18446744073136382760", 26},\
>>  {"\n", 1}], 10) = 52
>>
>> More complete strace output in this gist: https://gist.github.com/
>> 81ca7b1c6b8cc412b66951bb6d57e1ea
>>
>> Reproduce with e.g. OSProcess command: 'pwd' (it doesn't seem to matter
>> what command is chosen.)
>>
>> Anybody else see this / not see this? Any ideas?
>>
>> Could be that some of the magic in the UnixOSProcessPlugin fork method is
>> not working on 64-bit or with my toolchain...?
>>
>>
>>
>

Re: [Pharo-dev] OSProcess error with Linux 64-bit VM

[Thierry Goubier]

Hi Luke,

I'm using OSProcess for my day to day development work in 64bits on the
snap and default pharo vms, and it works.

Regards,

Thierry

2017-07-19 14:25 GMT+02:00 Luke Gorrie :

> Hoi,
>
> Does OSProcess work for other people with a 64-bit Linux VM?
>
> I am seeing strange errors specifically when I build in 64-bit mode:
> Processes always immediately print an obscure error and exit with status
> 127.
>
> The error is printed by the child process. It seems to contain some
> control characters, or a funky text encoding, and a large number for its
> error code.
>
> [pid 19070] writev(2, [{"/bin/sh", 7}, {": ", 2}, {" \n\2303\374\177", 6},
> {": ", 2}, {"", 0}, {"", 0}, {"\270\271\247\336;\177", 6}, {": ", 2},
> {"Error 18446744073136382760", 26},\
>  {"\n", 1}], 10) = 52
>
> More complete strace output in this gist: https://gist.github.com/
> 81ca7b1c6b8cc412b66951bb6d57e1ea
>
> Reproduce with e.g. OSProcess command: 'pwd' (it doesn't seem to matter
> what command is chosen.)
>
> Anybody else see this / not see this? Any ideas?
>
> Could be that some of the magic in the UnixOSProcessPlugin fork method is
> not working on 64-bit or with my toolchain...?
>
>
>

[Pharo-dev] OSProcess error with Linux 64-bit VM

[Luke Gorrie]

Hoi,

Does OSProcess work for other people with a 64-bit Linux VM?

I am seeing strange errors specifically when I build in 64-bit mode:
Processes always immediately print an obscure error and exit with status
127.

The error is printed by the child process. It seems to contain some control
characters, or a funky text encoding, and a large number for its error code.

[pid 19070] writev(2, [{"/bin/sh", 7}, {": ", 2}, {" \n\2303\374\177", 6},
{": ", 2}, {"", 0}, {"", 0}, {"\270\271\247\336;\177", 6}, {": ", 2},
{"Error 18446744073136382760", 26},\
 {"\n", 1}], 10) = 52

More complete strace output in this gist: https://gist.github.com/
81ca7b1c6b8cc412b66951bb6d57e1ea

Reproduce with e.g. OSProcess command: 'pwd' (it doesn't seem to matter
what command is chosen.)

Anybody else see this / not see this? Any ideas?

Could be that some of the magic in the UnixOSProcessPlugin fork method is
not working on 64-bit or with my toolchain...?

Re: [Pharo-dev] [Ann] Keccak hashing algorithm

[Norbert Hartl]

Eliot,

> Am 18.07.2017 um 22:26 schrieb Eliot Miranda :
> 
> Norbert,
> 
> On Tue, Jul 18, 2017 at 11:05 AM, Norbert Hartl  > wrote:
> Really great! I think we should move the Cryptography package from 
> smalltalkhub to github, refactor it and add goodies like this. We need a 
> strong crypto foundation.
> 
> I agree that refactoring and adding goodies is great.  But why does that 
> imply moving to github?  The Cryptography package has Squeak contributors too 
> and moving to github implies a fork.  

That fork happened already because there is a repository on smalltalkhub [1]. 
Lately I needed crypto support for a project of mine and I was searching for 
the last thing I could use. I was glad I've found the package Esteban did so I 
could use it in pharo. But I didn't know it was only the very last version that 
worked on pharo. But my Metacello setup somehow decided to load the second 
recent package which rendered my image unusable. From then I know that there 
are a lot of classes that have been incorporated in pharo which are present in 
the Cryptography package. I was asking for someone that maintains it and got no 
response.
It is clear to me that there is no easy way to maintain the package for both 
squeak and pharo. At least not while having one big package to share. It would 
need a bit of engineering. Then I remembered I was asking a similar question 
(about splitting the Cryptography package) years ago and I didn't get much 
positive resonance. Btw. this was my general feeling with the squeak community 
back then and the same reason I was one of the first being on the pharo train 
(sapphire back then).
To make a long story short. I really like spending some time for the smalltalk 
community. And I'm afraid I could kill my time and my mood while trying to get 
an agreement for something both squeak and pharo. So my current strategy is to 
care less and look (selfishly) forward. Maybe the better way is that each side 
has a look at the repository of the others and merges what is needed. 
Why github? Because I want a reliable repository where my business process runs 
on. Smalltalkhub is close to its final growth. And my impression is that if we 
would put the load from smalltalkhub onto squeaksource the only thing we would 
notice is a bright flash and silence after.
Furthermore after all those years it turns out that you have a hard time of you 
do version your stuff and you want versioning to work reliable. What really 
works for me is having a github repo, a BaselineOf my project and tags on 
commits. Anything else just does not work and/or is not reproducible. 

Norbert

[1] http://smalltalkhub.com/#!/~Cryptography/Cryptography 
 
> 
> Norbert
> 
> > Am 18.07.2017 um 19:10 schrieb Esteban A. Maringolo  > >:
> >
> > Great!
> >
> > I see you continue doing Ethereum related stuff ;-)
> >
> > Regards!
> > Esteban A. Maringolo
> >
> >
> > 2017-07-18 13:32 GMT-03:00 Santiago Bragagnolo 
> > >:
> >> Hi there!
> >>
> >> I am just releasing the first version of the Keccak-256 hashing algorithm.
> >> https://en.wikipedia.org/wiki/SHA-3 
> >>
> >> You can find it at: https://github.com/sbragagnolo/Keccak 
> >> 
> >>
> >> This  version is based on a javascript implementation:
> >> https://github.com/emn178/js-sha3 
> >>
> >> This implementation supports  as message: bytearray and ascii and utf-8
> >> strings.
> >>
> >>
> >> Soon i will be adding support to the rest of the Keccak family of hashing
> >> functions, since the implementations is quite configurable, is just need to
> >> add some constructors with specific configurations and tests for this other
> >> cases of usage.
> >>
> >>
> >> Here a onliner for building an image with the version v0.1:
> >>
> >> wget -O- 
> >> https://raw.githubusercontent.com/sbragagnolo/Keccak/v0.1/build.sh 
> >> 
> >> | bash
> >>
> >> Hope you find it useful :)
> >>
> >>
> >> Santiago
> >>
> >>
> 
> 
> 
> 
> -- 
> _,,,^..^,,,_
> best, Eliot

Re: [Pharo-dev] Epicea applying multiple changes

[Tudor Girba]

Hi,

I experienced the same issues. It seems somehow related that when we have 
multiple changes to the same method, not all changes are applied and we do not 
get back the latest version.

Cheers,
Doru


> On Jul 18, 2017, at 10:48 AM, Andrei Chis  wrote:
> 
> Hi,
> 
> Is there some known bug in Epicea when applying multiple changes at once in 
> Pharo 6?
> 
> I had a few crashes lately and each time when recovering the changes by 
> selecting multiple changes at once some changes are skipped. If I apply 
> manually each change it works. 
> 
> Cheers,
> Andrei

--
www.tudorgirba.com
www.feenk.com

"Things happen when they happen,
not when you talk about them happening."

[Pharo-dev] Need help for SmartTest/CORA

[Benoit Verhaeghe]

Hi everyone, 

I'm working on SmartTest/CORA. 
It's a plugin that help us with test. 
It shows us only the test we should run to well tests ours applications. 
And it will run automatically the tests (or not if you disable this option). 
It will be great if you can help me by installing it. 

You only have to execute this command : 

Metacello new githubUser: 'badetitou' project: 'TestsUsageAnalyser-CORAExtends' 
commitish: 'master' path: '.' ; baseline: 'TestsUsageAnalyserCORAExtends' ; 
load . 

You can also use the plugin with jenkins. 
Everything are explained here : 
http://badetitou.github.io/research/smalltalk/2017/07/05/CORA/ 


Tell me if you are in trouble during the installation 
Thanks for your help 
Benoit