Re: [Pharo-dev] FOSDEM

[François Stephany]

I'll be in the Smalltalk devroom the whole day ;)


On Wed, Jan 29, 2014 at 10:21 PM, Pharo4Stef  wrote:

> Not me even I would have liked so have fun for me :)
>
>
> Hi Gang,
>
> So, #FOSDEM is this week-end.
>
> I looked at the schedule, which looks interesting.
> https://fosdem.org/2014/schedule/track/smalltalk/
>
> Who's coming apart from the speakers ?
>
> Phil
>
>
>

Re: [Pharo-dev] Fosdem Videos and Pharo. 4 presentation

[François Stephany]

Rafael and I shot the videos but the FOSDEM staff is doing the
post-processing.
Sorry for the hiccups during recording  by the way, it was our first time
as cameramen ;)

Cheers,
Francois


On Wed, Feb 12, 2014 at 12:21 AM, Bernardo Ezequiel Contreras <
vonbecm...@gmail.com> wrote:

> Hi,
>They already know it, but they are busy.  be patient
>
> On Sun, Feb 09, 2014 at 08:06:03PM -0200, Bernardo Ezequiel Contreras
> wrote:
> > Hi,
> >   the following video
> > http://video.fosdem.org/2014/K4401/Saturday/Pharo4_Plans_and_Dreams.webm
> > doesn't contain the presentation by marcus denker, instead it contains
> the
> > "Objective Smalltalk" presentation by Marcel Weiher.
> > Could someone fix this, please?
>
> Thanks for letting us know.
>
> The video team will take a look as soon as they can, but please
> understand if it takes a while as they are still busy!
>
>
>

Re: [Pharo-dev] understanding postgresv2

[François Stephany]

Which one would you recommend? V2 or V3?
As I understand it, those version numbers refer to the PG Protocol version,
it is not the actual version of the library, right?


On Mon, Mar 3, 2014 at 8:25 AM, Sven Van Caekenberghe  wrote:

> Doru,
>
> Note that there is also the newer
>
>   http://www.squeaksource.com/PostgresV3.html
>
> which implements a more recent, incompatible version of the wire protocol
> between the client and server. I haven't tested it though, and I don't know
> if it is compatible at the higher level.
>
> Sven
>
> On 02 Mar 2014, at 17:34, Tudor Girba  wrote:
>
> > Hi,
> >
> > I am trying to understand how PostgresV2 is implemented because I would
> like to build some inspector support for it, and I encounter a couple of
> issues. In case anyone knows the answer, it would speed up my effort:
> >
> > - Why is result an instance variable in PGConnection? Making it a
> variable always returns the same object when executing a query and that is
> a bit of a pain.
> >
> > - Why does the PGResult have the possibility of holding multiple
> PGResultSets? When is it possible to have multiple at the same time? (when
> you execute a query, the result is being initialized)
> >
> > - When running something like
> > connection execute: 'select * from ...'
> > the PGResultSet already includes all rows of the query. Is it not
> possible to have a stream-like functionality in which the actual rows are
> retrieved only on demand? (a similar functionality exists in DBXTalk)
> >
> > - What is the difference between PGAsciiRow and PGDataRow?
> >
> > Doru
> >
> > --
> > www.tudorgirba.com
> >
> > "Every thing has its own flow"
>
>
>

Re: [Pharo-dev] Pharo behind ALLSTOCKER marketplace

[François Stephany]

This is a great overview, thanks for sharing.

On Mon, Oct 17, 2016 at 3:05 PM, Masashi UMEZAWA 
wrote:

> Hi all,
>
> From Torsten, I've received a request to post about some technical
> details of ALLSTOCKER (http://pharo.org/success/AllStocker) .
> I hope these notes will be interesting to Pharo web developers.
>
> - Seaside / Teapot
> We are using Seaside as a main framework for ALLSTOCKER marketplace.
> Seaside's component architecture is great for extending application in
> an organized way.
> ALLSTOCKER prototype was originally composed of only 3 class
> categories. Now these were gradually grown to 70 categories. But we
> still feel that they are manageable.
> We also use Teapot for building Web-based API in a quick way. Recently
> we've built webhook handlers for integration with other services.
>
> - Templating with Mustaside
> We need a lot of responsive-design web pages for supporting various
> mobile devices. (It is important especially for Southeast Asian
> countries, where tablets are popular than PCs).
> We would like to adopt existing Twitter Bootstrap templates for saving
> time. So, Mustaside was our choice.
> http://smalltalkhub.com/#!/~MasashiUmezawa/Mustaside
> Before Mustaside, there were a lot of noisy #div: sends in our code.
> Now they are gone.
>
> - Localization
> Our business target is world-wide. So localization is very important
> topic. Currently ALLSTOCKER supports 4 languages and we will add
> Chinese languages soon.
> Translation strings are not only in Smalltalk code, but also in
> Mustache templates. So we selected Soup for extracting translatable
> strings in those templates.
> http://smalltalkhub.com/#!/~PharoExtras/Soup
> For managing translations, we use Gettext package.
> http://smalltalkhub.com/#!/~PharoExtras/Gettext
>
> - Databases
> For transactional data, we chose Glorp. Although there are mapping
> costs, we prefer RDB (Postgres). It is reliable for handling precious
> order-related data.
> However, for supporting complex search of machines, we use Neo4j - a
> graph database. It supports very powerful query language called
> Cypher.
> We can avoid complex table joins and get aggregated results faster.
> http://smalltalkhub.com/#!/~MasashiUmezawa/Neo4reSt
>
> - Keyword search
> ALLSTOCKER supports free keyword search. We selected Elasticsearch for
> search-engine. Elasticsearch has elaborated searching facilities and
> those are easily accessible via REST API.
> We have extended the existing Elasticsearch client for Pharo 5.
> https://github.com/newapplesho/elasticsearch-smalltalk
>
> - Deployment
> We are using AWS Elastic Load Balancer and running Nginx as a
> front-end web server. Two back-end Pharo images are running and
> load-balanced with sticky sessions.
> It was sort of difficult to find the appropriate simultaneous number
> of database connections and Pharo processes. We feel ALLSTOCKER is
> pretty stable for now, but we need to adjust more for expanding our
> services.
>
> Best regards,
> --
> [:masashi | ^umezawa]
>
>

Re: [Pharo-dev] [Pharo-users] Slack, fragmentation and design information

[François Stephany]

There is a special price for non-profits organization:

> The Slack for Nonprofits program offers eligible organizations a *free
upgrade* to our Standard plan for teams of up to 250 members. For eligible
teams above that size, we offer an 85% discount on the Standard plan.

With 322 users it means that we still have to pay...

See https://get.slack.help/hc/en-us/articles/204368833-Slack-for-Nonprofits
for more information.


On Fri, Feb 10, 2017 at 1:18 PM, denker  wrote:

>
> >
> >> I share many of what you say… but in the other point of view, Slack as
> really worked and there is a lot more happening now in Slack + mailing list
> than what was before just in mailing list.
> >> But most of that is lost because of Slack policies (also Slack pricing
> model is impossible for a community as ours), and we need to find a
> solution for that.
> >
> > Yes this is too expensive for the Pharo consortium ?
> >
> It is per active member… which is defined as “has logged in the last 14
> days”. We have 322 members. No idea how many
> are active according to that definition.
>
> Fot 322 it would be: $8 per user per month. Which means $2576 per month or
> $25772 per year (taking the special yearly price into account).
>
> Marcus
>
>
>

Re: [Pharo-dev] FileSystem-Git status update

[François Stephany]

Thanks a lot for this work. I don't know for others but I hope it will
streamline my development workflow :)


On Fri, Mar 14, 2014 at 8:38 PM, Esteban Lorenzano wrote:

>
> On 14 Mar 2014, at 13:00, Vincent Blondeau <
> vincent.blond...@polytech-lille.net> wrote:
>
> > Le 14/03/2014 11:11, Max Leske a écrit :
> >> Hi everyone
> >>
> >> I promised to keep you posted about the progress, so here goes:
> >>
> >> - Esteban and I worked together yesterday and we got callbacks working
> >> - I will now do some cleanup so that its actually possible to work on
> libgit2 (some bindings have changed between versions 0.18 and 0.20 and I
> need to find out which)
> >> - Esteban and I will sit together again on Monday and prepare work for
> others / implement the object model on top of libgit2. I hope that we can
> separate tasks so that multiple people can work in parallel
> >>
> >> In my opinion we should be able to create local repositories, perform
> commits, switch branches and do checkouts by tuesday next week.
> Optimistically, fetch and push should also work by the end of the week.
> >> But that’s really just conjecture and I’ll keep you all posted.
> >>
> >> Just a reminder: at the moment we are working to get Git running with
> NativeBoost *at all*. Plans for abstraction, Monticello <-> Git, Github
> etc. should certainly be discussed, but don’t expect those things to be
> there at the end of next week.
> >>
> >> Max
> >>
> >>
> > That's seems cool !
> >
> > As you will use NativeBoost, do you plan to do it works under Windows 7 ?
>
> yep.
> Guys… the default answer to that is always: yes. Any package/addition is
> useless if it does not works in all the supported platforms (with possible
> exception of mobile platforms).
> Said so… you always has to start from some place… :)
>
> Esteban
>
> >
> > Vincent
> >
>
>
>

Re: [Pharo-dev] New Nautilus side bar buttons

[François Stephany]

Same for me, I never use them.

I don't really care what they look like but if there is a way to exend this
area with a plugin or completely remove it from the layout, the one posting
how to do it will get a beer/coffee in Cambridge this summer.


On Sun, Mar 30, 2014 at 4:32 PM, Sebastian Sastre <
sebast...@flowingconcept.com> wrote:

> I must confess that I never use those buttons but yours doesn’t look broken
>
> so, yes:  +1
>
>
>
> On Mar 28, 2014, at 1:57 PM, Benjamin <
> benjamin.vanryseghem.ph...@gmail.com> wrote:
>
> Hello guys,
>
> since I do not really like the new buttons introduced in Nautilus,
> and since the previous one were broken, I propose this new set
> of buttons based on the eclipse theme.
>
> 
> 
>
> Tell me what you think about it :)
> Ben
>
>
>

Re: [Pharo-dev] Pharo Consortium: New Bronze Member Ta Mère

[François Stephany]

The goal is reached then ;)


On Tue, Apr 8, 2014 at 9:50 PM, Pharo4Stef  wrote:

>
>
> > This is great news!
> >
> > I would vote for “Ta Mère” as the best company name ever.
>
> In fact I’m not that sure :)
> For the non french even if this is normally spelled french it can be
> interpreted as slang as nearly an insult.
> So this is quite provocative.
>
> > Alexandre
> >
> >
> > On Apr 8, 2014, at 2:53 PM, Marcus Denker 
> wrote:
> >
> >> The Pharo Consortium is very happy to announce that Ta Mère has joined
> the Consortium
> >> as a Bronze Industrial Member.
> >>
> >> More about
> >> - Ta Mère: http://tamere.eu
> >> - Pharo Consortium: http://consortium.pharo.org
> >>
> >>
> >> The goal of the Pharo Consortium is to allow companies to support the
> ongoing development and future of Pharo.
> >>
> >> Individuals can support Pharo via the Pharo Association:
> http://association.pharo.org
> >
> > --
> > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
> > Alexandre Bergel  http://www.bergel.eu
> > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
> >
> >
> >
> >
>
>
>

Re: [Pharo-dev] [ANN] Mapless a small framework for storing objects in a key->data fashion with no friction

[François Stephany]

Phil, can you describe your use case ?!


On Wed, Apr 16, 2014 at 11:20 PM, p...@highoctane.be wrote:

>
> I worked with Sebastian on using Mapless for my application.
>
> Just one word: Wow. This has potential
>
> Phil
>
> On Wed, Apr 16, 2014 at 9:17 PM, Sebastian Sastre <
> sebast...@flowingconcept.com> wrote:
>
>> Mapless
>>
>> Mapless is a small framework for storing objects in a key->data fashion
>> (i.e.: noSQL databases) without requiring any kind of object-data map. So
>> far only MongoDB is supported. It can use Redis for reactivity (pub/sub)
>> and cache.
>>  Motivation
>>
>> I wanted to persist objects with extremely *low friction* and extremely *low
>> maintenance*and great *scaling* and *availability* capabilities so
>> Mapless is totally biased towards that. This framework is what I came up
>> with after incorporating my experience 
>> withAggregate
>> .
>>
>> *There is no spoon…*
>>
>> *There is no object-relational impedance…*
>>
>> *There is no instVars…*
>> only persistence :D
>>
>> Code and instructions here:
>>
>> https://github.com/sebastianconcept/Mapless
>>
>> All MIT, enjoy
>>
>>  sebastian 
>>
>> o/
>>
>>
>>
>>
>>
>>
>

Re: [Pharo-dev] Debugging in Production Servers

[François Stephany]

I've quite often opened a REPL on Rails apps in the production environment.
You can basically execute everything on the production environment. This is
quite useful for checking what's going on (usually a mismatch between your
development/staging environment and the production one).

Beware that you do not connect to the serving process that your customer is
seeing. You just spin a new REPL process with the production settings. And
frankly it was usually more than enough to find what you need to fix.




On Fri, Apr 25, 2014 at 11:18 PM, Sebastian Sastre <
sebast...@flowingconcept.com> wrote:

>
> On Apr 25, 2014, at 5:48 PM, Sven Van Caekenberghe  wrote:
>
> look into a running server' to find or investigate a problem makes all the
> difference
>
>
> yeah, I agree. Logs are the last resource and hot debugs are unbeatable.
> They can cut costs *a lot* when investigating in the real environment
> where the problem happens and Smalltalk’s debugger is the closest thing to
> a developer-with-problem dream-tool that the industry can give.
>
>

Re: [Pharo-dev] Fast way to load package form github

[François Stephany]

I'm a bit lost of what is currently possible to do with git in Pharo. Is
there a place where you describe your workflow in a multi-developer
environment?

We currently use git flow[1] for our iOS, Android and Rails apps. We would
love to use the same for Pharo. What we are doing now is using a filetree
repository under a src/ directory sitting next to the image. We use
versionner to save all our packages in the filetree tree and then we `git
commit/push`.

It was working fine while I was alone but we are now two developers working
on this and I do not feel confident about this flow; merging filetree tree
in CLI doesn't sound like a good idea. probably not be practical.

The second developer is working on this since yesterday so we haven't yet
decided how we gonna handle this.

I would love to hear from people working with git and Pharo.


[1] http://nvie.com/posts/a-successful-git-branching-model/


On Sat, Apr 26, 2014 at 4:46 PM, GOUBIER Thierry wrote:

> Yuri,
>
> pure filetree will only allow you access to the latest version (HEAD) of
> the repository (and will only match if you load that precise version number
> as stored in the package metadata or if you don't specify a version
> number). You have to change the commit ID (and branch) via git clone, git
> checkout and git checkout -b before.
>
> github:// urls may be able to select a specific commit ID, but I don't
> know how. You can select the branch, however. Again, if you specify a
> version number for your package with a github:// url, the metadata of your
> package has to agree with you or it will refuse to load (you are able to
> see only the latest version of the package).
>
> gitfiletree:// urls allows you to select the branch and any version
> visible in the git history. Read-only gitfiletree:// urls reduce the git
> history to one commit, so all versions are listed as .1. (Note that
> gitfiletree:// urls with https are read-only).
>
> That said, if you found a way to refer a specific commit via github://,
> I'd really like to know how :)
>
> Thierry
> 
> De : Pharo-dev [pharo-dev-boun...@lists.pharo.org] de la part de Yuriy
> Tymchuk [yuriy.tymc...@me.com]
> Envoyé : samedi 26 avril 2014 12:11
> À : Pharo Development List
> Objet : Re: [Pharo-dev] Fast way to load package form github
>
> Do you know how to specify versions with pure filetree? I know that I can
> specify commit SHA or branch in URL, but can I somehow redefine version for
> a version definition?
>
> Uko
>
> On 26 Apr 2014, at 11:06, GOUBIER Thierry  wrote:
>
> > Yuri,
> >
> > I think the best would be a github:// url in a configuration.
> >
> > Shortest is something like:
> >
> > Gofer new
> >  url: 'http://smalltalkhub.com/mc/Yuri/ProjectOfYuri/main/';
> >  configurationOf: 'ProjectOfYuri';
> >  loadStable
> >
> > (with the github:// url inside ConfigurationOfProjectOfYuri)
> >
> > Note that I have added back https access to github in gitfiletree, but,
> still, it implies OSProcess and git command line access (but no need to
> register on github.com)
> >
> > Thierry
> > 
> > De : Pharo-dev [pharo-dev-boun...@lists.pharo.org] de la part de Yuriy
> Tymchuk [yuriy.tymc...@me.com]
> > Envoyé : samedi 26 avril 2014 09:34
> > À : Pharo Development List
> > Objet : Re: [Pharo-dev] Fast way to load package form github
> >
> > Yes, but this requires user to clone the repository, this is not as fast
> as just Gofer with Monticello. I know that there is a support for github://
> URIs in Metacello, but as far as I remember they don’t work in Gofer.
> >
> > Uko
> >
> > On 26 Apr 2014, at 09:25, Sven Van Caekenberghe  wrote:
> >
> >> Gofer with a filetree:// URL as package ?
> >>
> >> Using the Monticello UI Tool you can just add a repo, select filetree
> as type and load any package.
> >>
> >> On 26 Apr 2014, at 09:21, Yuriy Tymchuk  wrote:
> >>
> >>> Hi guys, sorry if there was already this question, but is there a fast
> way to load a package from github (saved with filetree)? I’m looking for
> some way to tell people: execute “this” and you will have my package in
> your image.
> >>>
> >>> Cheers
> >>> Uko
> >>
> >>
> >
> >
> >
>
>
>
>

Re: [Pharo-dev] Fast way to load package form github

[François Stephany]

Sounds *really* good!

Do you have a time goal for this integration (even rough estimate)?
Sorry if this sound stupid but are we far from an integration with, say,
the "Changes" tool?

If you need some help somewhere (money or manpower), I'm sure there are
quite a few people interesting in donating for this (Ta Mère is).

On Sat, Apr 26, 2014 at 7:32 PM, GOUBIER Thierry wrote:

>  Hi François,
>
> with gitfiletree://, there isn't any real place describing a
> multi-developper workflow because it is designed to work along existing
> workflows... as much as possible.
>
> In short, you work like you used to do in git, and gitfiletree ensures
> that the commit are properly made, that you have access to your development
> history (your true development history: the git one), and that pushes and
> pulls are made as painless as possible.
>
> After, you just manage your git the way you like it. Branches, merging,
> one branch per developper, whatever: gitfiletree:// will ensure that what
> you see inside Pharo is what you have done in git, and that what you do in
> Pharo is properly committed to git.
>
> Now, the bad thing: git merge conflicts :( When merging packages under
> git, some files will regularly(allways :() conflict: the version history of
> the package and the method properties. Whatever way you resolve those
> conflicts, gitfiletree:// will cope because it never reads them, but,
> still, having conflicts in git isn't cool.
>
> We have a better integration coming, through Max Leske work on integrating
> libgit to Pharo, and we will be able to solve some of the issues above ;)
>
> Thierry
>
>
>  ------
> *De :* Pharo-dev [pharo-dev-boun...@lists.pharo.org] de la part de
> François Stephany [tulipe.mouta...@gmail.com]
>
> *Envoyé :* samedi 26 avril 2014 19:06
> *À :* Pharo Development List
> *Objet :* Re: [Pharo-dev] Fast way to load package form github
>
> I'm a bit lost of what is currently possible to do with git in Pharo.
> Is there a place where you describe your workflow in a multi-developer
> environment?
>
>  We currently use git flow[1] for our iOS, Android and Rails apps. We
> would love to use the same for Pharo. What we are doing now is using a
> filetree repository under a src/ directory sitting next to the image. We
> use versionner to save all our packages in the filetree tree and then we
> `git commit/push`.
>
>  It was working fine while I was alone but we are now two developers
> working on this and I do not feel confident about this flow; merging
> filetree tree in CLI doesn't sound like a good idea. probably not be
> practical.
>
>  The second developer is working on this since yesterday so we haven't yet
> decided how we gonna handle this.
>
>  I would love to hear from people working with git and Pharo.
>
>
> [1] http://nvie.com/posts/a-successful-git-branching-model/
>
>
> On Sat, Apr 26, 2014 at 4:46 PM, GOUBIER Thierry 
> wrote:
>
>> Yuri,
>>
>> pure filetree will only allow you access to the latest version (HEAD) of
>> the repository (and will only match if you load that precise version number
>> as stored in the package metadata or if you don't specify a version
>> number). You have to change the commit ID (and branch) via git clone, git
>> checkout and git checkout -b before.
>>
>> github:// urls may be able to select a specific commit ID, but I don't
>> know how. You can select the branch, however. Again, if you specify a
>> version number for your package with a github:// url, the metadata of your
>> package has to agree with you or it will refuse to load (you are able to
>> see only the latest version of the package).
>>
>> gitfiletree:// urls allows you to select the branch and any version
>> visible in the git history. Read-only gitfiletree:// urls reduce the git
>> history to one commit, so all versions are listed as .1. (Note that
>> gitfiletree:// urls with https are read-only).
>>
>> That said, if you found a way to refer a specific commit via github://,
>> I'd really like to know how :)
>>
>> Thierry
>> 
>> De : Pharo-dev [pharo-dev-boun...@lists.pharo.org] de la part de Yuriy
>> Tymchuk [yuriy.tymc...@me.com]
>>  Envoyé : samedi 26 avril 2014 12:11
>>  À : Pharo Development List
>> Objet : Re: [Pharo-dev] Fast way to load package form github
>>
>> Do you know how to specify versions with pure filetree? I know that I can
>> specify commit SHA or branch in URL, but can I somehow redefine version for
>> a version definition?
>>
>> Uko
>>
>> On

Re: [Pharo-dev] Fast way to load package form github

[François Stephany]

Thank you both for the details!

Haha, I understand if you prefere to be on your own for the bindings (at
least while it's still in construction).
Thierry, If you need some feedback for the merge conflict resolution, I'll
be glad to help. Just ask :)

Max, I don't know how is your master thesis schedule organized but if
you're interested, we can maybe try to allocate a summer of code with the
libgit2 integration?

Cheers,
Francois



On Mon, Apr 28, 2014 at 11:08 AM, Max Leske  wrote:

>
> On 28.04.2014, at 10:42, François Stephany 
> wrote:
>
> Sounds *really* good!
>
> Do you have a time goal for this integration (even rough estimate)?
> Sorry if this sound stupid but are we far from an integration with, say,
> the "Changes" tool?
>
> If you need some help somewhere (money or manpower), I'm sure there are
> quite a few people interesting in donating for this (Ta Mère is).
>
>
> It’s on the way but we still have some way to go. I’ll be off the grid for
> the next 4 weeks and after that I’ll have to prepare for my exams. Still, I
> hope that I can show a prototype for using github around mid June (I’m
> pessimistic on purpose here). BTW: push and fetch via SSH / HTTPS already
> work (but you don’t want to see the code…).
>
> I’m glad you’re so enthusiastic but it’s a complex project and I don’t
> want to rush it (it’s also part of my master’s thesis btw).
>
> I’m posting updates from time to time with “FileSystem-Git update X” or
> similar in the subject if you want to follow. There’s also a dedicated
> mailing list: smalltalk-...@googlegroups.com
>
> To answer your questions:
> - no, there is no concrete plan other than “ships with Pharo4” (I hope…)
> - tool integration should be pretty straight forward once the bindings
> work. But I really can’t give you a date.
>
> As soon as there’s stuff that can be easily partitioned into workable
> chunks I’ll take to the mailing list. But I want to do the bindinds first,
> preferably on my own (requires a lot of special knowledge about git /
> libgit2 / NativeBoost). But thanks for the offer anyway. Much appreciated!
>
> Cheers,
> Max
>
>
>
> On Sat, Apr 26, 2014 at 7:32 PM, GOUBIER Thierry 
> wrote:
>
>>  Hi François,
>>
>> with gitfiletree://, there isn't any real place describing a
>> multi-developper workflow because it is designed to work along existing
>> workflows... as much as possible.
>>
>> In short, you work like you used to do in git, and gitfiletree ensures
>> that the commit are properly made, that you have access to your development
>> history (your true development history: the git one), and that pushes and
>> pulls are made as painless as possible.
>>
>> After, you just manage your git the way you like it. Branches, merging,
>> one branch per developper, whatever: gitfiletree:// will ensure that what
>> you see inside Pharo is what you have done in git, and that what you do in
>> Pharo is properly committed to git.
>>
>> Now, the bad thing: git merge conflicts :( When merging packages under
>> git, some files will regularly(allways :() conflict: the version history of
>> the package and the method properties. Whatever way you resolve those
>> conflicts, gitfiletree:// will cope because it never reads them, but,
>> still, having conflicts in git isn't cool.
>>
>> We have a better integration coming, through Max Leske work on
>> integrating libgit to Pharo, and we will be able to solve some of the
>> issues above ;)
>>
>> Thierry
>>
>>
>>  --
>> *De :* Pharo-dev [pharo-dev-boun...@lists.pharo.org] de la part de
>> François Stephany [tulipe.mouta...@gmail.com]
>>
>> *Envoyé :* samedi 26 avril 2014 19:06
>> *À :* Pharo Development List
>> *Objet :* Re: [Pharo-dev] Fast way to load package form github
>>
>> I'm a bit lost of what is currently possible to do with git in
>> Pharo. Is there a place where you describe your workflow in a
>> multi-developer environment?
>>
>>  We currently use git flow[1] for our iOS, Android and Rails apps. We
>> would love to use the same for Pharo. What we are doing now is using a
>> filetree repository under a src/ directory sitting next to the image. We
>> use versionner to save all our packages in the filetree tree and then we
>> `git commit/push`.
>>
>>  It was working fine while I was alone but we are now two developers
>> working on this and I do not feel confident about this flow; merging
>> filetree tree in CLI doesn't sound like a good idea. probably not be
>> practical.
>>
>>  The

Re: [Pharo-dev] Brainstorming Pharo4

[François Stephany]

As Kilon say, this is a personal wishlist. Any direction you mentioned is
worth and will have impact.

However, here's my personal top 5:

- **Git in the image**, that would be awesome to be able integrate the
gitflow way of developing in team. Easy branching/merging is a must.
- **Slots**. I still need to check the current implementation and see
what's possible (Property slots?) but as I have understood you've planned
even more for pharo4?
- **Text Editor with sensible keybindings**.
- **ARM support**
- **Athens**


On Wed, Jun 4, 2014 at 9:06 PM, jannik laval  wrote:

> Hi all,
>
> From my point of view, I like the progrss on the ARM VM.
> I hope to have an Android VM that works.
> Also I hope to see Pharo3.0 and Pharo4.0 working on iOS.
>
> Another question is about two interesting plugins: Mpeg3Plugin and
> CameraPlugin.
> Is it possible to integrate them in the VM build ?
>
> Thank you guys for all the work done.
> Jannik
>
>
> 2014-06-04 20:53 GMT+02:00 stepharo :
>
>
>>  Hi Esteban,
>>>
>>> As you mentioned a lot of new tools and protocols were introduced,
>>> people (me included) does not well about those ones.
>>> As an example I am slowly discovering announcement and now AFAIK the
>>> image use three different protocols for this: change/update, observer
>>> and Announcement!
>>>
>> Yes we know that the situation is not ideal.
>> We started to move more to announcement. The problem is that some of the
>> widgets
>> requires the change/update. For the observer I do not know what you mean.
>>
>>
>>> Personally I beg for a great Pharo 4.x series of iterative
>>> cleaning+consolidations.
>>>
>>> Thanks
>>>
>>> Hilaire
>>>
>>> Le 04/06/2014 17:36, Esteban Lorenzano a écrit :
>>>
 Hi,

 A couple of weeks ago we started to plan Pharo4. This work became
 stagnated for many reasons, but mainly because I needed to travel to
 Argentina.
 Now I'm slowly resuming the work and I wanted to share with you what we
 have been talking/dreaming.
 In esence, we have two important drivers for this release:

 1) Improving tools
 Turns out that we have introduced a lot of kernel improvements (opal
 compiler, layouts, slots, etc.) and tools are still not aware of them. Even
 worst: we have traits since a lot of time and our tools are still now aware
 enough to provide good interoperability.
 But not just that: we have introduced things that are not well used
 yet: keybindings (who do not want a better keybindings structure...
 coherent and editable?), spec should allow us to continue enhancing
 existing tools and to replace old ones.

 2) Modularisation
 One of the fundamental ideas behind Pharo is to provide a modular
 environment. But well... since Pharo start to the moment, we prepared
 things to allow it, but still few direct effort has been made.
 In our dreams, Pharo should be built starting for a small kernel image
 and adding different modules to get a complete version. In this idea
 Pharo=Kernel+GUI(Morphic)+Tools.
 This has huge advantages (I do not think is necesary to explain them,
 isn't ;)?)

 We brainstomed around this and we get this list of issues (not all of
 them directly related to the objectives, but well... good stuff also :) )

 Web site:
 - add catalog
 - add videos
 - enhance it in general

 Infrastructure:
 - support more vm platforms

 VM:
 - spur
 - 64bits
 - make vm embedable and UI independent (with SDL2 and OSWindow)

 Image:
 - Modularisation
 - Removing old compiler
 - Repackage Morphic (to allow better modularisation)
 - Athens (replace old bitblt)

 Tools
 - Replace changes with Ombu/Epicea
 - Replace sources with a better abstraction
 - Git support inside image (with libgit2 + tools)
 - Pass on Spec
 - Include Glamour?
 - Make Ring unloadable
 - Fonts with FreeType

 And lots of bugfixes :)

 We would like to exchange ideas with you.
 So, what do you think?

 Esteban




>>
>>
>
>
> --
>
> ~~Jannik Laval~~
> École des Mines de Douai
> Enseignant-chercheur
> http://www.jannik-laval.eu
> http://www.phratch.com
> http://car.mines-douai.fr/
>

[Pharo-dev] NaCL crypto_auth_hmacsha256

[François Stephany]

Does anyone use the NaCl package to sign with HMAC SHA256 but we can't find
what we need.

We've naively added:

apiCryptoAuthHMACSha256Output: outByteArray input: inByteArray inputLength:
inByteArrayLength key:keyByteArray

^self externalCallFailed

which failed with 'Unable to find function address'.

Any hint of how to do that?

Re: [Pharo-dev] NaCL crypto_auth_hmacsha256

[François Stephany]

I haven't but will do.

On 9 June 2014 11:37, François Stephany  wrote:
> Does anyone use the NaCl package to sign with HMAC SHA256 but we can't
find
> what we need.
>
> We've naively added:
>
> apiCryptoAuthHMACSha256Output: outByteArray input: inByteArray
inputLength:
> inByteArrayLength key:keyByteArray
>  module: 'libsodium'>
> ^self externalCallFailed
>
> which failed with 'Unable to find function address'.
>
> Any hint of how to do that?

Have you tried pinging Tony Garnock-Jones? Not because this is a
problem unique to libsodium, but since he wrote Smalltalk bindings for
it (
http://www.eighty-twenty.org/index.cgi/tech/smalltalk/nacl-for-squeak-and-pharo-20130601.html
)
he should know...

frank

Re: [Pharo-dev] NaCL crypto_auth_hmacsha256

[François Stephany]

Stupid me, Tony replied:

@fstephany It should be there. You want crypto_auth_hmacsha256_ref instead
> of crypto_auth_hmacsha256. See output of nm on libsodium.so.
>

It seems to work now  ('seems' because I run in another issue now).


On Mon, Jun 9, 2014 at 1:45 PM, François Stephany  wrote:

> I haven't but will do.
>
> On 9 June 2014 11:37, François Stephany  wrote:
> > Does anyone use the NaCl package to sign with HMAC SHA256 but we can't
> find
> > what we need.
> >
> > We've naively added:
> >
> > apiCryptoAuthHMACSha256Output: outByteArray input: inByteArray
> inputLength:
> > inByteArrayLength key:keyByteArray
> >  > module: 'libsodium'>
> > ^self externalCallFailed
> >
> > which failed with 'Unable to find function address'.
> >
> > Any hint of how to do that?
>
> Have you tried pinging Tony Garnock-Jones? Not because this is a
> problem unique to libsodium, but since he wrote Smalltalk bindings for
> it (
> http://www.eighty-twenty.org/index.cgi/tech/smalltalk/nacl-for-squeak-and-pharo-20130601.html
> )
> he should know...
>
> frank
>
>

Re: [Pharo-dev] news from block :)

[François Stephany]

What is bloc ?
I've searched in the pharo-dev list but couldn't find it :/


On Wed, Jun 11, 2014 at 2:26 PM, stepharo  wrote:

> looks so exciting...
>
> From: Alain Plantec 
> Subject: Bloc news
> Date: 11 Jun 2014 14:10:29 GMT+2
> To: Stéphane Ducasse 
> Cc: Alain Plantec 
>
> Name: Bloc-Core-AlainPlantec.15
> Author: AlainPlantec
> Time: 11 June 2014, 2:07:16.813171 pm
> UUID: d58ae82e-b5dd-41d9-bc31-a48c3e9e5cf1
> Ancestors: Bloc-Core-AlainPlantec.14
>
> - BlMorphs manage their submorphs with local coordinate.
> - Drawing and drag&drop has been adapted to local coordinate
> - Consequence: TransformationMorph should not be useful anymore because
> each morph has its own transform (not only TransformationMorph). Each morph
> uses its own transform to declare changed portions of its bounds and to
> draw its submorphs.
> - The world is no more a special morph:
> - the hand is owned by the space
> - the canvas and the display/redisplay of morphs are space
> responsibilities.
> This open the door to several worlds per space.
>
> Now the current global redrawing mechanism efficiency is not obvious.
> Next actions:
> - try to localize as much as possible the redrawing of morphs,
> - dig several Worlds for a space
> - start to comment and write a separate documentation with the help of
> Stephane :)
>
>
>

Re: [Pharo-dev] news from block :)

[François Stephany]

\o/


On Wed, Jun 11, 2014 at 4:23 PM, Camille Teruel 
wrote:

>
> On 11 juin 2014, at 15:31, François Stephany 
> wrote:
>
> What is bloc ?
>
> I've searched in the pharo-dev list but couldn't find it :/
>
>
> A Morphic clean/revamp lead by Alain and Stef.
>
>
> On Wed, Jun 11, 2014 at 2:26 PM, stepharo  wrote:
>
>> looks so exciting...
>>
>> From: Alain Plantec 
>> Subject: Bloc news
>> Date: 11 Jun 2014 14:10:29 GMT+2
>> To: Stéphane Ducasse 
>> Cc: Alain Plantec 
>>
>> Name: Bloc-Core-AlainPlantec.15
>> Author: AlainPlantec
>> Time: 11 June 2014, 2:07:16.813171 pm
>> UUID: d58ae82e-b5dd-41d9-bc31-a48c3e9e5cf1
>> Ancestors: Bloc-Core-AlainPlantec.14
>>
>> - BlMorphs manage their submorphs with local coordinate.
>> - Drawing and drag&drop has been adapted to local coordinate
>> - Consequence: TransformationMorph should not be useful anymore because
>> each morph has its own transform (not only TransformationMorph). Each morph
>> uses its own transform to declare changed portions of its bounds and to
>> draw its submorphs.
>> - The world is no more a special morph:
>> - the hand is owned by the space
>> - the canvas and the display/redisplay of morphs are space
>> responsibilities.
>> This open the door to several worlds per space.
>>
>> Now the current global redrawing mechanism efficiency is not obvious.
>> Next actions:
>> - try to localize as much as possible the redrawing of morphs,
>> - dig several Worlds for a space
>> - start to comment and write a separate documentation with the help of
>> Stephane :)
>>
>>
>>
>
>

[Pharo-dev] Azure Storage Library

[François Stephany]

Hi there,

I'm implementing a library to interact with Azure Storage. I'm already
blocked at the first step: generate the authentication header.

The header generation is described there:
http://msdn.microsoft.com/en-us/library/azure/dd179428.aspx

An SDK exists for Ruby:
https://github.com/Azure/azure-sdk-for-ruby

I've taken the tests from the Ruby SDK to drive my implementation. I have a
mismatch that I can't solve with the authentication header.

You can run the tests or execute the small scenario from the
AZSharedKeyAuth class comment to see where the problem is (i've created a
temporary storage account for testing, the account name and key are in the
class comment).

Apparently something goes wrong in the
signature= Base64(HMAC-SHA256(UTF8(StringToSign))).

My StringToSign seems to be ok (cr vs lf vs crlf possibly put some mess).

My code is there:
http://smalltalkhub.com/#!/~francois/AzureStorage

Can someone have a look? If you're a company that can send invoices, I
don't mind to pay consulting fees if you can help...

Re: [Pharo-dev] Azure Storage Library

[François Stephany]

Hello Sven,


> You might want to have a look at the code in Zinc-AWS (group AWS in
> ConfigurationOfZincHTTPComponents), in particular ZnAWSS3Client and
> ZnAWSS3RequestSignatureTool - it is using similar request signing but does
> HMAC-SHA1.
>

Thanks! I wasn't aware of the existence of ZnAWS.
Actually, i'm currently using the HMAC-SHA256 implementation of the
CloudFork.


>
> From a quick glance at the documentation, it seems you have to use
> Character lf (\r) else you'll get the wrong result.
>

I'm using withUnixLineEndings to ensure the Character lf line ending. You
meant \n instead of \r, right?


> Have you tried signing the examples (canonical strings) in the
> documentation and comparing with their result ?
>

The problem is that they don't tell with which key they've signed the
string. It makes it quite hard to decompose the problem and see where
something breaks.
The tests in the Ruby SDK are not really useful neither. I'll the other
SDKs, maybe the tests are more revealing.



> If you really can't make it work, we can discuss further.
>

I'll try a bit more and come back if needed!

Thanks !

Re: [Pharo-dev] Azure Storage Library

[François Stephany]

> >
> > You might want to have a look at the code in Zinc-AWS (group AWS in
> ConfigurationOfZincHTTPComponents), in particular ZnAWSS3Client and
> ZnAWSS3RequestSignatureTool - it is using similar request signing but does
> HMAC-SHA1.
> >
> > Thanks! I wasn't aware of the existence of ZnAWS.
> > Actually, i'm currently using the HMAC-SHA256 implementation of the
> CloudFork.
>
> Is that an all Smalltalk implementation ?
> Because it would be really good to have SHA256 in the image.
>

Yes it is. The class comment says:

"
http://csrc.nist.gov/publications/fips/fips180-2/fips180-2withchangenotice.pdf
This class represnets the implementation of CFSHA256 as describied above.
Please direct questions or comments about this implementation to Ron
Teitelbaum: r...@usmedrec.com
This code was extensively coppied from SHA1 by Luciano Notarfrancesco
lnotarfrance...@yahoo.com
"

It seems to work for AWS, I wonder what I'm doing wrong here...

Re: [Pharo-dev] Azure Storage Library

[François Stephany]

Got it.

It's super stupid.
The key they give to feed the HMAC-SHA256 is actually a base64 string that
needs to be decoded.
It's not mentionned in the docs and I missed the constructor of the Signer
in Ruby:

# Public: Initialize the Signer.
#
# access_key - The access_key encoded in Base64. Defaults to the one
#  in the global configuration.
def initialize(access_key=Azure.config.storage_access_key)
  @access_key = Base64.strict_decode64(access_key)
end

Tests are passing now :)

Thanks for your patience Sven!



On Thu, Jun 19, 2014 at 4:01 PM, Sven Van Caekenberghe  wrote:

>
> On 19 Jun 2014, at 15:52, François Stephany 
> wrote:
>
> >
> > >
> > > You might want to have a look at the code in Zinc-AWS (group AWS in
> ConfigurationOfZincHTTPComponents), in particular ZnAWSS3Client and
> ZnAWSS3RequestSignatureTool - it is using similar request signing but does
> HMAC-SHA1.
> > >
> > > Thanks! I wasn't aware of the existence of ZnAWS.
> > > Actually, i'm currently using the HMAC-SHA256 implementation of the
> CloudFork.
> >
> > Is that an all Smalltalk implementation ?
> > Because it would be really good to have SHA256 in the image.
> >
> > Yes it is. The class comment says:
> >
> > "
> >
> http://csrc.nist.gov/publications/fips/fips180-2/fips180-2withchangenotice.pdf
> This class represnets the implementation of CFSHA256 as describied above.
> > Please direct questions or comments about this implementation to Ron
> Teitelbaum: r...@usmedrec.com
> > This code was extensively coppied from SHA1 by Luciano Notarfrancesco
> lnotarfrance...@yahoo.com
> > "
> >
> > It seems to work for AWS, I wonder what I'm doing wrong here...
>
> You have to be 100% sure that the SHA256, HMAC-SHA256 code works (as
> opposed to the SHA1, HMAC-SHA1 code) then you absolutely need examples: a
> known canonical string and keys with a Base64 signature output. Start by
> making sure you can replicate this in your reference implementation (Ruby,
> Java, C#) and then start to go to Pharo.
>
> Look *very* carefully at each element of the canonical string, one letter
> difference, one header, punctuation, whitespace, case, date or time format
> difference will break the whole thing - that is the point of being a
> signature.
>
>
>

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

[François Stephany]

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) ?

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

[François Stephany]

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  wrote:

> I want to have a look, if you tell me where to look...
>
> On 19 Jun 2014, at 18:03, Max Leske  wrote:
>
> >
> > On 19.06.2014, at 17:59, François Stephany 
> 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

[François Stephany]

Thanks Sven!


On Wed, Jun 25, 2014 at 10:46 AM, Sven Van Caekenberghe 
wrote:

> A patch mechanism ?
>
> That would be cool indeed, although probably not doable in all cases.
>
> On 25 Jun 2014, at 10:23, Norbert Hartl  wrote:
>
> > Wouldn't it be wonderful if we could install packages from a ticket in
> the image? Something like
> >
> > - get 3.0 image
> > - fix from issue 12345 and issue 45678 and...
> > - install own own packages
> > - deploy
> >
> > It would be so well documented :)
> >
> > Norbert
> >
> > Am 25.06.2014 um 08:47 schrieb Sven Van Caekenberghe :
> >
> >> I only did it in 3.0
> >> The file out is attached to the slice - it is 100% standalone
> >>
> >> On 25 Jun 2014, at 00:45, Norbert Hartl  wrote:
> >>
> >>> thank you, Sven. Did you try this in 3.0, too. I would need it there!
> >>>
> >>> Norbert
> >>>
> >>>> Am 25.06.2014 um 00:11 schrieb Sven Van Caekenberghe :
> >>>>
> >>>> https://pharo.fogbugz.com/f/cases/13395/Add-SHA256-HashFunction
> >>>>
> >>>> cleaned up, documented, properly packaged.
> >>>>
> >>>> Passes some test vectors.
> >>>>
> >>>> I changed the handling of the empty stream.
> >>>>
> >>>>> On 24 Jun 2014, at 23:03, Sven Van Caekenberghe 
> wrote:
> >>>>>
> >>>>> Hi Jan,
> >>>>>
> >>>>> I loaded just the class CFSHA256 and it worked perfectly (I didn't
> expect anything else).
> >>>>>
> >>>>> I tried some examples from Wikipedia (
> http://en.wikipedia.org/wiki/Sha256#Examples_of_SHA-2_variants):
> >>>>>
> >>>>> (CFSHA256 hashMessage: 'The quick brown fox jumps over the lazy
> dog') hex.
> 'd7a8fbb307d7809469ca9abcb0082e4f8d5651e46d3cdb762d02d0bf37c9e592'
> >>>>>
> >>>>> (CFSHA256 hashMessage: 'The quick brown fox jumps over the lazy
> dog.') hex.
> 'ef537f25c895bfa782526529a9b63d97aa631564d5d789c2b765448c8635fb6c'
> >>>>>
> >>>>> So I will rename the class to SHA256, moving it to System-Hashing
> and add SHA256Tests for starters.
> >>>>>
> >>>>> Sven
> >>>>>
> >>>>>> On 20 Jun 2014, at 17:01, Jan van de Sandt 
> 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  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
> >>>>
> >>>>
> >>>
> >>
> >>
> >
> >
>
>
>

[Pharo-dev] Configuration readonly archives

[François Stephany]

We've been bitten a few times at Ta Mère by the problem of changing
metacello configuration.

At the moment, we rely on the policy of "you should never change a
Metacello version once it has been published". Of course this is fragile
and we've ended up with different code loaded in different environment
while we were expecting stuff to be identical.

Has anyone already tempted to centralize configurations/package in a
read-only place (S3? Azure Storage?). Something like RubyGems or similar.
It may be completely stupid to have centralised system but I'm not
satisfied with the infastructure supporting our configurations.

Am I the only one having this problem? How do you handle it?

[Pharo-dev] [ANN] HelloPharo - webapp deployment tool

[François Stephany]

Hello,

At Ta Mère, we are used to deploy Ruby/Rails application with Heroku or on
VPS with Capistrano. Almost everybody uses the same tools and techniques in
the Rails community so deployment is quite easy once you grasp the process.

The same process was quite frustrating with Pharo. To solve that, we've
built HelloPharo. It is a tool to deploy small apps to a Linux VPS/VM.

It is heavily inspired by Capistrano, it prones convention over
configuration and it wants to be full stack (e.g., serve the assets,
restart the processes). It is built with Ansible.

We haven't released a fixed version yet but the tool starts to be in a
good-enough shape to be shown. We want to grab some feedback and fix the
most obvious limitations (see the README for more) before releasing version
0.1.0.

If you or your company uses a well defined process to deploy pharo webapps,
we are all ears. We think that having a canonical way to deploy simple apps
is a must if we want to see wider Pharo adoption for small web companies.
This process *must* be Unix friendly if we want to attract Python or Ruby
people. Most of them are Devops anyway, the command line is their friend,
NOT something they want to avoid.

Pull requests (for code or instructions in the README) are more than
welcome. The code and the documentation are MIT licensed.

https://github.com/fstephany/hello-pharo/

Cheers,
Francois

Re: [Pharo-dev] [ANN] HelloPharo - webapp deployment tool

[François Stephany]

Oh, I forgot to mention Sven. He wrote the original
http://stfx.eu/pharo-server/
We basically stole all his Bash-fu to build the main script:

https://github.com/fstephany/hello-pharo/blob/master/app

Thanks a lot Sven!


On Thu, Aug 14, 2014 at 1:02 PM, François Stephany <
tulipe.mouta...@gmail.com> wrote:

> Hello,
>
> At Ta Mère, we are used to deploy Ruby/Rails application with Heroku or on
> VPS with Capistrano. Almost everybody uses the same tools and techniques in
> the Rails community so deployment is quite easy once you grasp the process.
>
> The same process was quite frustrating with Pharo. To solve that, we've
> built HelloPharo. It is a tool to deploy small apps to a Linux VPS/VM.
>
> It is heavily inspired by Capistrano, it prones convention over
> configuration and it wants to be full stack (e.g., serve the assets,
> restart the processes). It is built with Ansible.
>
> We haven't released a fixed version yet but the tool starts to be in a
> good-enough shape to be shown. We want to grab some feedback and fix the
> most obvious limitations (see the README for more) before releasing version
> 0.1.0.
>
> If you or your company uses a well defined process to deploy pharo
> webapps, we are all ears. We think that having a canonical way to deploy
> simple apps is a must if we want to see wider Pharo adoption for small web
> companies. This process *must* be Unix friendly if we want to attract
> Python or Ruby people. Most of them are Devops anyway, the command line is
> their friend, NOT something they want to avoid.
>
> Pull requests (for code or instructions in the README) are more than
> welcome. The code and the documentation are MIT licensed.
>
> https://github.com/fstephany/hello-pharo/
>
> Cheers,
> Francois
>

Re: [Pharo-dev] [Pharo-users] [ANN] HelloPharo - webapp deployment tool

[François Stephany]

Good idea, I add monit as one of the next step.

Load balancing is not supported at all. But we could change the nginx
config file to load balance between two images. And maybe make something
for Seaside and its state (sticky sessions?). I haven't done enough of this
to actually take an informed decision.

I'll update the README to be more clear about what is done behind the
scene. Showing the tree of directories created by HelloPharo will be worth
a thousand words (especially if you've used capistrano before).


On Thu, Aug 14, 2014 at 3:13 PM, Sven Van Caekenberghe  wrote:

>
> On 14 Aug 2014, at 13:08, François Stephany 
> wrote:
>
> > Oh, I forgot to mention Sven. He wrote the original
> http://stfx.eu/pharo-server/
> > We basically stole all his Bash-fu to build the main script:
> >
> > https://github.com/fstephany/hello-pharo/blob/master/app
> >
> > Thanks a lot Sven!
>
> You're welcome, François. BTW, I am still using that script for all my
> deploys.
>
> I didn't immediately see it, but does your solution include something for
> process monitoring and automatic restarts (like monit) and/or some basic
> load balancing ? In my experience the combination of these two makes for a
> more robust solution. Maybe that is the next step ;-)
>
> Sven
>
> > On Thu, Aug 14, 2014 at 1:02 PM, François Stephany <
> tulipe.mouta...@gmail.com> wrote:
> > Hello,
> >
> > At Ta Mère, we are used to deploy Ruby/Rails application with Heroku or
> on VPS with Capistrano. Almost everybody uses the same tools and techniques
> in the Rails community so deployment is quite easy once you grasp the
> process.
> >
> > The same process was quite frustrating with Pharo. To solve that, we've
> built HelloPharo. It is a tool to deploy small apps to a Linux VPS/VM.
> >
> > It is heavily inspired by Capistrano, it prones convention over
> configuration and it wants to be full stack (e.g., serve the assets,
> restart the processes). It is built with Ansible.
> >
> > We haven't released a fixed version yet but the tool starts to be in a
> good-enough shape to be shown. We want to grab some feedback and fix the
> most obvious limitations (see the README for more) before releasing version
> 0.1.0.
> >
> > If you or your company uses a well defined process to deploy pharo
> webapps, we are all ears. We think that having a canonical way to deploy
> simple apps is a must if we want to see wider Pharo adoption for small web
> companies. This process *must* be Unix friendly if we want to attract
> Python or Ruby people. Most of them are Devops anyway, the command line is
> their friend, NOT something they want to avoid.
> >
> > Pull requests (for code or instructions in the README) are more than
> welcome. The code and the documentation are MIT licensed.
> >
> > https://github.com/fstephany/hello-pharo/
> >
> > Cheers,
> > Francois
> >
>
>
>

Re: [Pharo-dev] [Pharo-business] [Pharo-users] [ANN] HelloPharo - webapp deployment tool

[François Stephany]

Ah ! I was also thinking about a cookie to keep user identity, I hate to
re-login because of an expired session. I was looking for a good name,
"login-token" sounds good :)

Why do you keep it 14 days only ? Is there a reason ? I planned to make it
valid much longer than that...


On Thu, Aug 14, 2014 at 10:27 PM, Sven Van Caekenberghe 
wrote:

>
> On 14 Aug 2014, at 15:21, François Stephany 
> wrote:
>
> > Good idea, I add monit as one of the next step.
> >
> > Load balancing is not supported at all. But we could change the nginx
> config file to load balance between two images. And maybe make something
> for Seaside and its state (sticky sessions?). I haven't done enough of this
> to actually take an informed decision.
>
> Here is some information on how I did it recently using nginx and Seaside:
>
>   http://forum.world.st/Nginx-Load-Balancing-Experiences-td4750823.html
>
> The stickiness is by client IP.
>
> It is also possible to do route based stickiness in Seaside and using Zinc
> (see ZnServer>>#route:), but I know only how to do that with Apache 2 (it
> is a paying option for nginx sadly).
>
> Of course, in most cases you will have to do some session state sharing
> between instances. I used memcached for that.
>
> > I'll update the README to be more clear about what is done behind the
> scene. Showing the tree of directories created by HelloPharo will be worth
> a thousand words (especially if you've used capistrano before).
> >
> >
> > On Thu, Aug 14, 2014 at 3:13 PM, Sven Van Caekenberghe 
> wrote:
> >
> > On 14 Aug 2014, at 13:08, François Stephany 
> wrote:
> >
> > > Oh, I forgot to mention Sven. He wrote the original
> http://stfx.eu/pharo-server/
> > > We basically stole all his Bash-fu to build the main script:
> > >
> > > https://github.com/fstephany/hello-pharo/blob/master/app
> > >
> > > Thanks a lot Sven!
> >
> > You're welcome, François. BTW, I am still using that script for all my
> deploys.
> >
> > I didn't immediately see it, but does your solution include something
> for process monitoring and automatic restarts (like monit) and/or some
> basic load balancing ? In my experience the combination of these two makes
> for a more robust solution. Maybe that is the next step ;-)
> >
> > Sven
> >
> > > On Thu, Aug 14, 2014 at 1:02 PM, François Stephany <
> tulipe.mouta...@gmail.com> wrote:
> > > Hello,
> > >
> > > At Ta Mère, we are used to deploy Ruby/Rails application with Heroku
> or on VPS with Capistrano. Almost everybody uses the same tools and
> techniques in the Rails community so deployment is quite easy once you
> grasp the process.
> > >
> > > The same process was quite frustrating with Pharo. To solve that,
> we've built HelloPharo. It is a tool to deploy small apps to a Linux VPS/VM.
> > >
> > > It is heavily inspired by Capistrano, it prones convention over
> configuration and it wants to be full stack (e.g., serve the assets,
> restart the processes). It is built with Ansible.
> > >
> > > We haven't released a fixed version yet but the tool starts to be in a
> good-enough shape to be shown. We want to grab some feedback and fix the
> most obvious limitations (see the README for more) before releasing version
> 0.1.0.
> > >
> > > If you or your company uses a well defined process to deploy pharo
> webapps, we are all ears. We think that having a canonical way to deploy
> simple apps is a must if we want to see wider Pharo adoption for small web
> companies. This process *must* be Unix friendly if we want to attract
> Python or Ruby people. Most of them are Devops anyway, the command line is
> their friend, NOT something they want to avoid.
> > >
> > > Pull requests (for code or instructions in the README) are more than
> welcome. The code and the documentation are MIT licensed.
> > >
> > > https://github.com/fstephany/hello-pharo/
> > >
> > > Cheers,
> > > Francois
> > >
> >
> >
> >
> > ___
> > Pharo-business mailing list
> > pharo-busin...@lists.pharo.org
> > http://lists.pharo.org/mailman/listinfo/pharo-business_lists.pharo.org
>
>

Re: [Pharo-dev] [Pharo-users] [ANN] Pharo Days 2015

[François Stephany]

I can host one or two people at my place in Mons, Belgium (~1h drive from
INRIA Lille) for free. I can drive to the conference both days.

In the best case, I might have some friends to host me (us?) in Lille. So
we can have some beers without having to drive.

Francois


On Wed, Oct 29, 2014 at 4:18 PM, Sven Van Caekenberghe  wrote:

> We are excited to announce the details so far for the Pharo Days 2015, to
> be held on Thursday January 29 and Friday January 30 at INRIA, Lille,
> France.
>
>
>   https://medium.com/@svenvc/pharo-days-2015-6336d6ee2a23
>
>
> We’ll update this page moving forward. You can ask questions on the any of
> the Pharo mailing lists or you can email the Pharo Board.
>
>
> Official registration is not yet open, but there is a Doodle that should
> give an indication of who is coming and that can help us plan resources.
>
>
>   http://doodle.com/icxtazwfq76caxf8
>
>
> The Pharo Board
>

Re: [Pharo-dev] A configuration framework

[François Stephany]

We use http://smalltalkhub.com/#!/~TaMere/DeployUtils
It loads a JSON files in the "config/" directory sitting next to the image.
It handles multi-environment with the "PHARO_ENV" env var.

We use this to have a different configuration in
development/staging/production

Check the DUEnvironment class for usage.



On Tue, Nov 4, 2014 at 9:01 AM, p...@highoctane.be 
wrote:

> Yes, there is Sebastian Sastre's ConfigurationFiles which work very well.
>
> http://www.smalltalkhub.com/#!/~sebastianconcept/ConfigurationFiles
>
> HTH
> Phil
>
> On Tue, Nov 4, 2014 at 5:15 PM, Damien Cassou 
> wrote:
>
>> Hi,
>>
>> I need a framework that will help me make my application configurable.
>> This framework must save and load the application's configuration
>> to/from a file. I'm not happy with the System-Settings framework (that
>> I'm currently using for the Pharo Launcher) that saves executable code
>> because, when the application evolves, the old code in the
>> configuration file might not work with the new application.
>>
>> Is there something around already?
>>
>> --
>> Damien Cassou
>> http://damiencassou.seasidehosting.st
>>
>> "Success is the ability to go from one failure to another without
>> losing enthusiasm."
>> Winston Churchill
>>
>>
>

Re: [Pharo-dev] A configuration framework

[François Stephany]

And the real repo is:

https://github.com/fstephany/DeployUtils



On Tue, Nov 4, 2014 at 9:41 AM, François Stephany  wrote:

> We use http://smalltalkhub.com/#!/~TaMere/DeployUtils
> It loads a JSON files in the "config/" directory sitting next to the
> image. It handles multi-environment with the "PHARO_ENV" env var.
>
> We use this to have a different configuration in
> development/staging/production
>
> Check the DUEnvironment class for usage.
>
>
>
> On Tue, Nov 4, 2014 at 9:01 AM, p...@highoctane.be 
> wrote:
>
>> Yes, there is Sebastian Sastre's ConfigurationFiles which work very well.
>>
>> http://www.smalltalkhub.com/#!/~sebastianconcept/ConfigurationFiles
>>
>> HTH
>> Phil
>>
>> On Tue, Nov 4, 2014 at 5:15 PM, Damien Cassou 
>> wrote:
>>
>>> Hi,
>>>
>>> I need a framework that will help me make my application configurable.
>>> This framework must save and load the application's configuration
>>> to/from a file. I'm not happy with the System-Settings framework (that
>>> I'm currently using for the Pharo Launcher) that saves executable code
>>> because, when the application evolves, the old code in the
>>> configuration file might not work with the new application.
>>>
>>> Is there something around already?
>>>
>>> --
>>> Damien Cassou
>>> http://damiencassou.seasidehosting.st
>>>
>>> "Success is the ability to go from one failure to another without
>>> losing enthusiasm."
>>> Winston Churchill
>>>
>>>
>>
>

[Pharo-dev] French speaking Pharo company

[François Stephany]

Hi there,

I'm writing a proposal for a potential customer. Given the complex model,
I'd like to implement the backend and webservice in Pharo (instead of Ruby
on Rails).

Is there any of you working in a service company doing Pharo Development
for backends? The customer is french and might be more comfortable going
with Pharo if he knows that there are backups in case we disappear.

Cheers,
Francois

[Pharo-dev] MongoTalk: new place on smalltalkhub

[François Stephany]

Hi,

I've just created a new team for MongoTalk on SmalltalkHub:

http://www.smalltalkhub.com/#!/~MongoTalkTeam

The old repo (http://www.smalltalkhub.com/#!/~francois/MongoTalk) will stay
just in case some scripts rely on it but you should update to the new repo:

http://www.smalltalkhub.com/#!/~MongoTalkTeam/mongotalk

I've created a version 1.5.1 in the Metacello configuration to reflect the
repo migration.
Shout at me if I missed something!

Cheers,
Fa

(Many thanks to Norbert for pushing the migration ;)