Re: [Pharo-dev] AWS SDK for Pharo

[Jan van de Sandt]

Hi,

Here is yet another (very) partial implementation of an AWS SDK for Pharo:
https://github.com/jvdsandt/pharo-aws-toolbox

But it does have the latest (V4) signing algoritm!

It would be very nice if you can generate a Pharo implemetation of an AWS
service from a meta description!

Jan.

On Wed, Feb 27, 2019 at 2:02 PM Sven Van Caekenberghe  wrote:

> Hi,
>
> This is interesting indeed.
> The meta descriptions in JSON are cool and most probably usable.
> It would be a huge project, though, given how many APIs/products there
> are, even with auto generation.
>
> A long time ago I did a AWS S3 client that is still part of Zinc HTTP
> Components (https://github.com/svenvc/zinc), although I believe the
> authentication/signing model is old now.
>
> Sven
>
> > On 27 Feb 2019, at 12:37, Stefan Krecher 
> wrote:
> >
> > Hi,
> > I'm aware that there is already an AWS SDK implementation for Smalltalk
> ( https://github.com/newapplesho/aws-sdk-smalltalk )
> > This implementation doesn't seem to be a complete implementation to
> access all AWS services.
> > Using a live-programming environment like Pharo would be so cool,
> flexible, productive and intuitive to control/ manage AWS resources - but
> implementing the SDK by hand is probably not a good idea, since it would be
> so hard to keep it up-to-date, because AWS adds new features weekly ...
> > I contacted the AWS enterprise support and they gave me some great hints.
> > There are many 3rd party SDK's available that utilizes the json files
> provided in botocore to automatically generate SDKs:
> > Botocore:
> > https://github.com/boto/botocore
> > Example service.json:
> https://github.com/boto/botocore/blob/develop/botocore/data/ecs/2014-11-13/service-2.json
> > They can then  automatically generate an SDK based off of these json
> definitions. One example of this is Rusoto, the AWS SDK for Rust:
> > Rusoto: https://github.com/rusoto/rusoto
> >
> > Automatic generation portion:
> > https://github.com/rusoto/rusoto/tree/master/service_crategen
> >
> > Would anyone interested in supporting this kind of project?
> > What would be a good starting-point?
> > Although I am (to be honest: I was) a Smalltalk-Programmer, I have too
> little experience with Pharo - but maybe others might find this useful. It
> would also be useful to "spread the word" - AWS scripting/ automation is so
> popular, there would be so many occasions to showcase Pharo + AWS or to
> create Products that are based on AWS services.
> >
> > Regards
> > Stefan
>
>
>

Re: [Pharo-dev] [ANN] Pharo Lambda Runtime

[Jan van de Sandt]

Hi Tim,

On Fri, Dec 28, 2018 at 4:49 PM Tim Mackinnon  wrote:

> Hi Jan - reading through your docs, this looks very promising as I hadn’t
> got as far as using the api gateway - I was just connecting to the internal
> Alexa service.
>
> One thing I didn’t quite understand - you mention specifying a HANDLER as
> an env variable, but your example description doesn’t seem to show where
> that is set? Is it in the bootstrap file (also is that bootrap.sh or just
> simply bootstrap?
>

Up til now I have configured my Lambda functions mostly via the AWS
Console. When you create your function you must upload your code, specify
the type of runtime and give the name of the handler. For a Java runtime
this is the name of the main class, so for the Smalltalk implementation I
choose something similar. If you want you can leave this item empty or set
it to "Provided" and just hardcode the startup class in the image or in the
bootstrap file.

And are there any file attributes to set on that file?). It strikes me that
> rather than using an env variable - why don’t you specify the handler class
> when you invoke the image as the last command line option? (That is what I
> did in my example - or is it faster to query an env variable? Personally I
> find it easier to see it more explicitly on the command line).
>
> I also notice you include NeoJson - did you need that? I found that the
> default Ston reader was more than adequate for reading the json  that was
> sent over (and so it’s one less pre-req).
>
> With NeoJSON you can create mappings to serialize/deserialize custom
Smalltalk classes to Json. I use this functionality in the CloudWatch-Logs
interface to handle the request and response objects. I don't think this is
possible with STON.


> I haven’t yet fully understood the runtime layer - is this simply a zip
> file with the vm + files and without the image? Previously I had to add all
> of that in the zip I uploaded for each function, but this sounds like it
> simplifies things a lot. Do you have a script you used to create that - I
> ask as I found that trimming down the size of that made a difference to
> load times for Alexa (eg there are lots of sound and graphics dll’s you can
> remove - which I have in my script, and possibly, I could add to what you
> have done).
>

Yes, the layers are a great new feature. My layer just includes a standard
Pharo 64 bits VM without any additions or removals. I made this one by
hand, a script would be a better idea! You can remove shared libraries that
you don't need. I think the most important thing is that the image does not
load/initialize any unnecessary libraries.

>
> Equally, I also figured out the command line fu for uploading and
> registering your Lamba so it works in a ci - this might also be worthy of
> inclusion.
>
> Yes, a CI job that can build a 'deployment' image and that can upload this
image to AWS Lambda would be a great feature!


> Anyway, l’ll Give it a go and see how the results compare - it was
> surprisingly fast using the js shim - but this seems like a much better
> solution.
>
> Thanks for sharing - it’s an executing world.
>
> Tim
>
> Thanks for your comments!
Jan.


>
>
>
> Sent from my iPhone
> On Fri, 28 Dec 2018, at 11:35 AM, Jan van de Sandt wrote:
>
> Hi Tim,
>
> Yes, I read that you got Pharo working via the Javascript runtime. It
> should now be much easier and faster.
>
> I still have to figure out the best way to create a deployment image. With
> the new bootstrap/modular setup of Pharo 7 it should be possible to create
> a lean-and-mean runtime image that can run in the cheapest 128MB max. ram
> configuration.
>
> Jan.
>
> On Thu, Dec 27, 2018 at 2:18 PM Tim Mackinnon  wrote:
>
> Cool - I was using a JS shim and had asked AWS many times why they
> couldn’t open it up wider...
>
> Now I’m back from my travels I’ll reincarnate my previous work and see how
> it works with this. I was looking forward to doing more with Lambda, so
> this is great timing.
>
>  Tim
>
> Sent from my iPhone
>
> On 27 Dec 2018, at 10:32, Jan van de Sandt  wrote:
>
> Hi,
>
> Last month Amazon extended their serverless runtime platform AWS Lambda
> with support for custom runtimes. I created a Pharo Lambda Runtime so now
> we can implement Lambda functions in Smalltalk and easily deploy them on
> the Lambda platform. Lamba has quite a large "free-tier", more than enough
> to do some experiments and to host small applications for free.
>
> See the GitHub project for more details
> https://github.com/jvdsandt/pharo-aws-toolbox
>
> Cheers,
> Jan.
>
>
>

Re: [Pharo-dev] [ANN] Pharo Lambda Runtime

[Jan van de Sandt]

Hi Tim,

Yes, I read that you got Pharo working via the Javascript runtime. It
should now be much easier and faster.

I still have to figure out the best way to create a deployment image. With
the new bootstrap/modular setup of Pharo 7 it should be possible to create
a lean-and-mean runtime image that can run in the cheapest 128MB max. ram
configuration.

Jan.

On Thu, Dec 27, 2018 at 2:18 PM Tim Mackinnon  wrote:

> Cool - I was using a JS shim and had asked AWS many times why they
> couldn’t open it up wider...
>
> Now I’m back from my travels I’ll reincarnate my previous work and see how
> it works with this. I was looking forward to doing more with Lambda, so
> this is great timing.
>
>  Tim
>
> Sent from my iPhone
>
> On 27 Dec 2018, at 10:32, Jan van de Sandt  wrote:
>
> Hi,
>
> Last month Amazon extended their serverless runtime platform AWS Lambda
> with support for custom runtimes. I created a Pharo Lambda Runtime so now
> we can implement Lambda functions in Smalltalk and easily deploy them on
> the Lambda platform. Lamba has quite a large "free-tier", more than enough
> to do some experiments and to host small applications for free.
>
> See the GitHub project for more details
> https://github.com/jvdsandt/pharo-aws-toolbox
>
> Cheers,
> Jan.
>
>

[Pharo-dev] [ANN] Pharo Lambda Runtime

[Jan van de Sandt]

Hi,

Last month Amazon extended their serverless runtime platform AWS Lambda
with support for custom runtimes. I created a Pharo Lambda Runtime so now
we can implement Lambda functions in Smalltalk and easily deploy them on
the Lambda platform. Lamba has quite a large "free-tier", more than enough
to do some experiments and to host small applications for free.

See the GitHub project for more details
https://github.com/jvdsandt/pharo-aws-toolbox

Cheers,
Jan.

Re: [Pharo-dev] LMDB

[Jan van de Sandt]

Hi,

On OSX you can use Homebrew to install LMDB. This will install the 64bit
version. If you want the 32bit version you will have to tweak the recipe.

Jan.

On Fri, Nov 11, 2016 at 11:32 AM, Stephan Eggermont <step...@stack.nl>
wrote:

> On 05/11/16 13:55, Jan van de Sandt wrote:
>
>> LMDB is a lean, mean and very fast storage engine. One limitation is
>> that you need a 64bit proces before you can store more than 2GB of data.
>> That was a downside for me until very recently :-)
>>
>> LMDB is a low level key-value storage engine that runs on a single host.
>> But if that is what you are looking for it seems pretty good. I haven't
>> used it in any production systems yet. But it is used as a storage
>> engine in quite a few open source projects. For example OpenLDAP.
>>
>
> Do I really need to compile LMDB myself?
>
> Stephan
>
>
>

Re: [Pharo-dev] Instructions for Pharo 6 64bits

[Jan van de Sandt]

Hi Esteban,

Instantiations is also busy porting their VM to 64bits. They have already
created a new API for OStructures so that the offsets are re calculated
based on the platform alignment rules and the VM type [1].

I know Pharo is open source and VA Smalltalk is not. But a bit of
cooperation should be possible I think. Both platforms benefit if libraries
are easy to port and not re-inventing this wheel saves time.

Jan.

[1]
http://www.instantiations.com/docs/862/wwhelp/wwhimpl/js/html/wwhelp.htm#href=pr/stpr451.html


On Sat, Nov 5, 2016 at 3:10 PM, Esteban Lorenzano <esteba...@gmail.com>
wrote:

>
> > On 5 Nov 2016, at 12:27, Thierry Goubier <thierry.goub...@gmail.com>
> wrote:
> >
> > Le 05/11/2016 à 12:12, Jan van de Sandt a écrit :
> >> Hi,
> >>
> >> With the latest 64bits VM (201611042126) and image (60282) UFFI is also
> >> looking good. I'm testing a small library of mine [1] to interface with
> >> LMDB [1], a memory mapped key-value database. Almost all tests are
> >> green. This is great progress!
> >
> > Hi Jan,
> >
> > did you have to change your UFFI definitions to match the 64bits version
> of your lib?
>
> no.
> but structures do change (because of sizes, of course).
> I’m thinking a way to define a generic representation (keeping offsets
> somewhere instead hardcoding it), but for now they have to be redefined for
> each platform.
>
> Esteban
>
> >
> > Thierry
> >
> >> I only ran into one issue, a PrimitiveFailed error with
> >> #basicIdentityHash in the SmallFloat64 class.
> >>
> >> Cheers,
> >> Jan.
> >>
> >> [1] http://smalltalkhub.com/#!/~JanVanDeSandt/LightningMDB
> >> [2] https://symas.com/products/lightning-memory-mapped-database/
> >>
> >>
> >> On Fri, Oct 28, 2016 at 11:56 AM, Esteban Lorenzano <
> esteba...@gmail.com
> >> <mailto:esteba...@gmail.com>> wrote:
> >>
> >>VM here: http://bintray.com/estebanlm/pharo-vm/build#files/
> >><http://bintray.com/estebanlm/pharo-vm/build#files/>
> >>Image here: http://files.pharo.org/get-files/60/pharo-64.zip
> >><http://files.pharo.org/get-files/60/pharo-64.zip>
> >>
> >>this is still not official (that’s why is not in official place) so
> >>there are a couple of known problems:
> >>
> >>- version format is different, and that breaks some things in image
> >>that depends on it to know what happens
> >>- command line is different and probably you’ll need to play a bit
> >>with options (one or two dashes).
> >>- UFFI has some failing tests (but most of it works).
> >>
> >>I would appreciate some help to report and/or fix the emerging
> >>problems.
> >>
> >>cheers,
> >>Esteban
> >>
> >>>On 28 Oct 2016, at 10:39, Thierry Goubier
> >>><thierry.goub...@gmail.com <mailto:thierry.goub...@gmail.com>>
> wrote:
> >>>
> >>>Hi all,
> >>>
> >>>anybody knows how to get (and test) the 64bits version of the
> >>>Pharo vm and image?
> >>>
> >>>Thanks,
> >>>
> >>>Thierry
> >>
> >>
> >
> >
>
>
>

Re: [Pharo-dev] Instructions for Pharo 6 64bits

[Jan van de Sandt]

Hi Sven,

LMDB is a lean, mean and very fast storage engine. One limitation is that
you need a 64bit proces before you can store more than 2GB of data. That
was a downside for me until very recently :-)

LMDB is a low level key-value storage engine that runs on a single host.
But if that is what you are looking for it seems pretty good. I haven't
used it in any production systems yet. But it is used as a storage engine
in quite a few open source projects. For example OpenLDAP.

Jan.

On Sat, Nov 5, 2016 at 1:43 PM, Jan van de Sandt <jvdsa...@gmail.com> wrote:

> Hi,
>
> The only thing I had to do was to regenerate the accessors of the
> structure classes MDBValue and MDBStat. The offsets for the fields are
> different on 32 versus 64 bit systems. Perhaps we can think of a way to
> generate the field accessors of structure classes such that they work in
> both environments.
>
> For now just you can just use #rebuildFieldAccessors
>
> Jan.
>
> On Sat, Nov 5, 2016 at 12:27 PM, Thierry Goubier <
> thierry.goub...@gmail.com> wrote:
>
>> Le 05/11/2016 à 12:12, Jan van de Sandt a écrit :
>>
>>> Hi,
>>>
>>> With the latest 64bits VM (201611042126) and image (60282) UFFI is also
>>> looking good. I'm testing a small library of mine [1] to interface with
>>> LMDB [1], a memory mapped key-value database. Almost all tests are
>>> green. This is great progress!
>>>
>>
>> Hi Jan,
>>
>> did you have to change your UFFI definitions to match the 64bits version
>> of your lib?
>>
>> Thierry
>>
>> I only ran into one issue, a PrimitiveFailed error with
>>> #basicIdentityHash in the SmallFloat64 class.
>>>
>>> Cheers,
>>> Jan.
>>>
>>> [1] http://smalltalkhub.com/#!/~JanVanDeSandt/LightningMDB
>>> [2] https://symas.com/products/lightning-memory-mapped-database/
>>>
>>>
>>> On Fri, Oct 28, 2016 at 11:56 AM, Esteban Lorenzano <esteba...@gmail.com
>>> <mailto:esteba...@gmail.com>> wrote:
>>>
>>> VM here: http://bintray.com/estebanlm/pharo-vm/build#files/
>>> <http://bintray.com/estebanlm/pharo-vm/build#files/>
>>> Image here: http://files.pharo.org/get-files/60/pharo-64.zip
>>> <http://files.pharo.org/get-files/60/pharo-64.zip>
>>>
>>> this is still not official (that’s why is not in official place) so
>>> there are a couple of known problems:
>>>
>>> - version format is different, and that breaks some things in image
>>> that depends on it to know what happens
>>> - command line is different and probably you’ll need to play a bit
>>> with options (one or two dashes).
>>> - UFFI has some failing tests (but most of it works).
>>>
>>> I would appreciate some help to report and/or fix the emerging
>>> problems.
>>>
>>> cheers,
>>> Esteban
>>>
>>> On 28 Oct 2016, at 10:39, Thierry Goubier
>>>> <thierry.goub...@gmail.com <mailto:thierry.goub...@gmail.com>>
>>>> wrote:
>>>>
>>>> Hi all,
>>>>
>>>> anybody knows how to get (and test) the 64bits version of the
>>>> Pharo vm and image?
>>>>
>>>> Thanks,
>>>>
>>>> Thierry
>>>>
>>>
>>>
>>>
>>
>>
>

Re: [Pharo-dev] Instructions for Pharo 6 64bits

[Jan van de Sandt]

Hi,

The only thing I had to do was to regenerate the accessors of the structure
classes MDBValue and MDBStat. The offsets for the fields are different on
32 versus 64 bit systems. Perhaps we can think of a way to generate the
field accessors of structure classes such that they work in both
environments.

For now just you can just use #rebuildFieldAccessors

Jan.

On Sat, Nov 5, 2016 at 12:27 PM, Thierry Goubier <thierry.goub...@gmail.com>
wrote:

> Le 05/11/2016 à 12:12, Jan van de Sandt a écrit :
>
>> Hi,
>>
>> With the latest 64bits VM (201611042126) and image (60282) UFFI is also
>> looking good. I'm testing a small library of mine [1] to interface with
>> LMDB [1], a memory mapped key-value database. Almost all tests are
>> green. This is great progress!
>>
>
> Hi Jan,
>
> did you have to change your UFFI definitions to match the 64bits version
> of your lib?
>
> Thierry
>
> I only ran into one issue, a PrimitiveFailed error with
>> #basicIdentityHash in the SmallFloat64 class.
>>
>> Cheers,
>> Jan.
>>
>> [1] http://smalltalkhub.com/#!/~JanVanDeSandt/LightningMDB
>> [2] https://symas.com/products/lightning-memory-mapped-database/
>>
>>
>> On Fri, Oct 28, 2016 at 11:56 AM, Esteban Lorenzano <esteba...@gmail.com
>> <mailto:esteba...@gmail.com>> wrote:
>>
>> VM here: http://bintray.com/estebanlm/pharo-vm/build#files/
>> <http://bintray.com/estebanlm/pharo-vm/build#files/>
>> Image here: http://files.pharo.org/get-files/60/pharo-64.zip
>> <http://files.pharo.org/get-files/60/pharo-64.zip>
>>
>> this is still not official (that’s why is not in official place) so
>> there are a couple of known problems:
>>
>> - version format is different, and that breaks some things in image
>> that depends on it to know what happens
>> - command line is different and probably you’ll need to play a bit
>> with options (one or two dashes).
>> - UFFI has some failing tests (but most of it works).
>>
>> I would appreciate some help to report and/or fix the emerging
>> problems.
>>
>> cheers,
>> Esteban
>>
>> On 28 Oct 2016, at 10:39, Thierry Goubier
>>> <thierry.goub...@gmail.com <mailto:thierry.goub...@gmail.com>>
>>> wrote:
>>>
>>> Hi all,
>>>
>>> anybody knows how to get (and test) the 64bits version of the
>>> Pharo vm and image?
>>>
>>> Thanks,
>>>
>>> Thierry
>>>
>>
>>
>>
>
>

Re: [Pharo-dev] Instructions for Pharo 6 64bits

[Jan van de Sandt]

Hi,

With the latest 64bits VM (201611042126) and image (60282) UFFI is also
looking good. I'm testing a small library of mine [1] to interface with
LMDB [1], a memory mapped key-value database. Almost all tests are green.
This is great progress!

I only ran into one issue, a PrimitiveFailed error with #basicIdentityHash
in the SmallFloat64 class.

Cheers,
Jan.

[1] http://smalltalkhub.com/#!/~JanVanDeSandt/LightningMDB
[2] https://symas.com/products/lightning-memory-mapped-database/


On Fri, Oct 28, 2016 at 11:56 AM, Esteban Lorenzano 
wrote:

> VM here: http://bintray.com/estebanlm/pharo-vm/build#files/
> Image here: http://files.pharo.org/get-files/60/pharo-64.zip
>
> this is still not official (that’s why is not in official place) so there
> are a couple of known problems:
>
> - version format is different, and that breaks some things in image that
> depends on it to know what happens
> - command line is different and probably you’ll need to play a bit with
> options (one or two dashes).
> - UFFI has some failing tests (but most of it works).
>
> I would appreciate some help to report and/or fix the emerging problems.
>
> cheers,
> Esteban
>
> On 28 Oct 2016, at 10:39, Thierry Goubier 
> wrote:
>
> Hi all,
>
> anybody knows how to get (and test) the 64bits version of the Pharo vm and
> image?
>
> Thanks,
>
> Thierry
>
>
>

[Pharo-dev] UnifiedFFI Interrupted system call error on OSX

[Jan van de Sandt]

Hi,

I'm helping with the port of LibGit [1] from Pharo 4 to Pharo 5 [2]. This
project provides Smalltalk bindings for the libgit2 library. Very useful
for better Git support in Pharo. The port means using the new UnifiedFFI
instead of NativeBoost.

The project is still in the alpha stage but a lot of the libgit2 features
are already accessible. Some libgit2 calls access the network. For example
to clone a repository or to push a commit. The calls that use https work on
Linux and on Windows but on OSX we always get the following error in Pharo
5:

LGit_GIT_ERROR: Failed to connect to github.com: Interrupted system call.

In Pharo4/NB this error does not occur. Could this be an issue in UFFI or
perhaps in the VM ?

To reproduce the problem in Pharo 5 (after loading [2]):


| repo |
repo := LGitRepository on: 'my-test-repo' asFileReference.
repo cloneHttps: 'https://github.com/theseion/LibGit.git'


Jan.

[1] https://github.com/theseion/LibGit
[2] https://github.com/jvdsandt/LibGit

Re: [Pharo-dev] RBRefactoring docs

[Jan van de Sandt]

Hi,

I think this is the original documentation:
http://www.refactory.com/tools/refactoring-browser

Jan.

On Sat, Apr 16, 2016 at 5:42 PM, Peter Uhnák  wrote:

> Hi,
>
> is there any documentation for RBRefactoring?
> Since there are not even class comments the only thing I found is judging
> from tests.
>
> Thanks,
> Peter
>

Re: [Pharo-dev] Example implementation of associations with Slots in Pharo 4.0

[Jan van de Sandt]

Hello,

Thanks for your suggestions. I have improved the naming and definition to
this:

Object subclass: #SlotExampleMovie
slots: {
#name.
#year.
#director = ToOneRelationSlot inverse: #directedMovies inClass:
#SlotExamplePerson.
#actors = ToManyRelationSlot inverse: #actedInMovies inClass:
#SlotExamplePerson }
classVariables: {  }
category: 'SlotAssociations-Tests-Example'

Because it is for now just an example I haven't renamed the Slot classes
yet.

Jan.




On Tue, Feb 24, 2015 at 8:03 AM, Marcus Denker marcus.den...@inria.fr
wrote:


 On 23 Feb 2015, at 22:34, Ben Coman b...@openinworld.com wrote:

 I haven't played with the relation example yet, but will real soon.  Just
 some initial thoughts...

 I like RelationSlot.  To me association seems one-way while a relation is
 two-way.

 btw, Is there some reason to not match the syntax of the often cited paper
 Flexible Object Layout ?
 I see one advantage is that its easier to read all the slot names
 vertically aligned.

 Object subclass: #SlotExampleMovie
 slots: {
 #name.
 #year.
 #director = ToOneRelationSlot opposite: #directedMovies class:
 #SlotExamplePerson.
 #actors = ToManyRelationSlot opposite: #actedInMovies  class: 
 #SlotExamplePerson.
 }
 classVariables: {  }
 category: 'SlotAssociations-Tests-Example'


 Also maybe an alternative slot class name so that it reads more like a
 sentence... #director related to one #directedMovies in class
 #SlotExamplePerson

 Object subclass: #SlotExampleMovie
 slots: {
 #name.
 #year.
 #director = RelatedToOne inverse: #directedMovies inClass:
 #SlotExamplePerson.
 #actors = RelatedToMany inverse: #actedInMovies  inClass: #SlotExamplePerson.
 }
 classVariables: {  }
 category: 'SlotAssociations-Tests-Example'


 Something like those would be good… yes, I think having the slot name in
 front is important.

 Marcus

[Pharo-dev] Example implementation of associations with Slots in Pharo 4.0

[Jan van de Sandt]

Today I experimented a little with the new Slots feature of Pharo 4.0. As
an example I implemented support for associations/relationships.

With it you can link two slots together so an update on one side will also
update the other side of the association/relationship.

I used these Movie and Person classes for testing:

Object subclass: #SlotExampleMovie
slots: {
#name.
#year.
ToOneAssociationSlot named: #director target: #SlotExamplePerson inverse:
#directedMovies.
ToManyAssociationSlot named: #actors target: #SlotExamplePerson inverse:
#actedInMovies }
classVariables: {  }
category: 'SlotAssociations-Tests-Example'
Object subclass: #SlotExamplePerson
slots: {
#name.
ToManyAssociationSlot named: #directedMovies target: #SlotExampleMovie
inverse: #director.
ToManyAssociationSlot named: #actedInMovies target: #SlotExampleMovie
inverse: #actors }
classVariables: {  }
category: 'SlotAssociations-Tests-Example'

With this definition the director of a Movie must be a Persion instance.
When you set the director of a movie this movie is automatically added to
the directedMovies collection of that person. Off course it also works the
other way around.

It took very little code to add these association slots. I think Slots are
a really nice addition to Pharo! If anyone wants to have a look at the code:

MCHttpRepository
location: 'http://smalltalkhub.com/mc/JanVanDeSandt/Stuff/main'
user: ''
password: ''

Jan.

Re: [Pharo-dev] Cloudfork HMAC-SHA256 in System-Hashing

[Jan van de Sandt]

Hello,

I added the SHA256 class to Cloudfork a few years ago. The class was mostly
copied from the Cryptography [1] project.

Cheers,
Jan.

[1] http://www.squeaksource.com/Cryptography/


On Fri, Jun 20, 2014 at 10:56 AM, François Stephany 
tulipe.mouta...@gmail.com wrote:

 Max,

 Yes, it's usable as the SHA1 package already there (without HMAC so). I'm
 no expert in those stuff but I don't get SHA256 base implementation.
 Someone with more knowledge can probably tell ;)

 Sven,

 The bare minimum to load it is:

 Gofer it
 smalltalkhubUser: 'JanVanDeSandt' project: 'Cloudfork';
 package: 'Cloudfork-Common';
 package: 'Cloudfork-Pharo-Platform';
 load.

 The implementation is in Cloudfork-Pharo-Platform.



 On Thu, Jun 19, 2014 at 6:20 PM, Sven Van Caekenberghe s...@stfx.eu
 wrote:

 I want to have a look, if you tell me where to look...

 On 19 Jun 2014, at 18:03, Max Leske maxle...@gmail.com wrote:

 
  On 19.06.2014, at 17:59, François Stephany tulipe.mouta...@gmail.com
 wrote:
 
  Does it make sense from a license point of view and practical point of
 view to include the CloudFork HMAC-SHA256 implementation (CFSH256 class) in
 the System-Hashing package (in  where there's already SHA1 and MD5) ?
 
  Can Cloudfork HMAC-SHA256 be easily parameterized with, say, an SHA256
 base implementation? Or does it require extra stuff? In the former case I
 probably wouldn’t add it. In the latter case it’s open for discussion.
 Personally, I think it belongs into a separate package, not into
 System-Hashing.
 
  Cheers,
  Max

Re: [Pharo-dev] Cloudfork HMAC-SHA256 in System-Hashing

[Jan van de Sandt]

And I think it's a good idea to make SHA2 hash functions part of the
System-Hashing
package!


On Fri, Jun 20, 2014 at 5:01 PM, Jan van de Sandt jvdsa...@gmail.com
wrote:

 Hello,

 I added the SHA256 class to Cloudfork a few years ago. The class was
 mostly copied from the Cryptography [1] project.

 Cheers,
 Jan.

 [1] http://www.squeaksource.com/Cryptography/


 On Fri, Jun 20, 2014 at 10:56 AM, François Stephany 
 tulipe.mouta...@gmail.com wrote:

 Max,

 Yes, it's usable as the SHA1 package already there (without HMAC so). I'm
 no expert in those stuff but I don't get SHA256 base implementation.
 Someone with more knowledge can probably tell ;)

 Sven,

 The bare minimum to load it is:

 Gofer it
 smalltalkhubUser: 'JanVanDeSandt' project: 'Cloudfork';
 package: 'Cloudfork-Common';
 package: 'Cloudfork-Pharo-Platform';
 load.

 The implementation is in Cloudfork-Pharo-Platform.



 On Thu, Jun 19, 2014 at 6:20 PM, Sven Van Caekenberghe s...@stfx.eu
 wrote:

 I want to have a look, if you tell me where to look...

 On 19 Jun 2014, at 18:03, Max Leske maxle...@gmail.com wrote:

 
  On 19.06.2014, at 17:59, François Stephany tulipe.mouta...@gmail.com
 wrote:
 
  Does it make sense from a license point of view and practical point
 of view to include the CloudFork HMAC-SHA256 implementation (CFSH256 class)
 in the System-Hashing package (in  where there's already SHA1 and MD5) ?
 
  Can Cloudfork HMAC-SHA256 be easily parameterized with, say, an SHA256
 base implementation? Or does it require extra stuff? In the former case I
 probably wouldn’t add it. In the latter case it’s open for discussion.
 Personally, I think it belongs into a separate package, not into
 System-Hashing.
 
  Cheers,
  Max