September 2018 - Pharo-dev - lists.pharo.org

[Pharo 7.0-dev] Build #1281: 22433-Review-FloatTest-testCopySignTo-and-testSign

by ci-pharo-ci-jenkins2＠inria.fr

There is a new Pharo build available! The status of the build #1281 was: SUCCESS. The Pull Request #1835 was integrated: "22433-Review-FloatTest-testCopySignTo-and-testSign" Pull request url: https://github.com/pharo-project/pharo/pull/1835 Issue Url: https://pharo.fogbugz.com/f/cases/22433 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Sept. 30, 2018

[Pharo 7.0-dev] Build #1280: 22489-cleanup--CompilationContext-and-doSemanticAnalysis

by ci-pharo-ci-jenkins2＠inria.fr

There is a new Pharo build available! The status of the build #1280 was: SUCCESS. The Pull Request #1830 was integrated: "22489-cleanup--CompilationContext-and-doSemanticAnalysis" Pull request url: https://github.com/pharo-project/pharo/pull/1830 Issue Url: https://pharo.fogbugz.com/f/cases/22489 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Sept. 30, 2018

[Pharo 7.0-dev] Build #1279: 22498-TextEditorsaveContentsInFile-should-not-use-FileStream

by ci-pharo-ci-jenkins2＠inria.fr

There is a new Pharo build available! The status of the build #1279 was: FAILURE. The Pull Request #1839 was integrated: "22498-TextEditorsaveContentsInFile-should-not-use-FileStream" Pull request url: https://github.com/pharo-project/pharo/pull/1839 Issue Url: https://pharo.fogbugz.com/f/cases/22498 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Sept. 30, 2018

Re: [Pharo-dev] [Pharo-users] [ANN] Success story Mobility Map

by Pierce Ng

On Wed, Sep 26, 2018 at 07:49:10PM +0200, Norbert Hartl wrote: >>> And a lot more. This is a coarse grained overview over the >>> architecture. Iâm happy to answer further questions about this. >>> [very nice writeup] Hi Norbert, Very nice write-up, thanks. What persistence mechanism are you using - Gemstone/S, Glorp, Voyage, ...? Pierce

Sept. 30, 2018

Re: [Pharo-dev] [ANN] Migrated Artefact to GitHub

by Stephane Ducasse

Thanks norbert. I accept your apologies. Stef On Sat, Sep 29, 2018 at 8:39 PM Stephane Ducasse <stepharo.self(a)gmail.com> wrote: > > Hi Peter > > Just a note to say that I appretiate your attitude and we know it each other. > I will try to use your tool when I will migrate my projects. > > Stef > > On Sat, Sep 29, 2018 at 2:32 PM Peter Uhnak <i.uhnak(a)gmail.com> wrote: > >> > >> - you're stealing > > > > > > Sorry, I absolutely did not intend the evoke the notion of "stealing". > > My perspective is... I am spending time to migrate someone else's code, so the last thing I want is someone burning my energy and complaining that I voided their contribution. > > > > I don't give a fuck if someone migrates my contribution and strips the authorship (and when I do care I don't need to rely on others to prove it). > > But I want to cover my ass from backlash from other people, because I know it will happen and I know that people will complain (which is exactly what happened to you). > > > > So preventing the appropriation of code is not about you taking credit for other person's code, but you being covered from them accusing you of it. (It probably sounds like I am pathologically defensive, but dealing with people is exhausting for me.) > > > >> > >>> * it is sending bad signals to potential contributors that we can scrub them anytime we want > >>> > >>> as you yourself have said: > >>> > @People try to avoid to piss on good will of others. > >>> Yet this is what it feels like to some when traces of their contributions are voided. > >> > >> > >> And this is my third point. This "stealing" idea is mainly a matter of manners. > > > > > > Again, I didn't intend "stealing". It's about preventing people from thinking "They don't give a fuck about their contributors, so why I should give a fuck about contributing?". It can be dispiriting for them, even if they don't care about the code itself. And they will complain... and who needs that? > > > >> If instead of bashing on people, we wanted to discuss on how to actually FIX the thing, here are my 2 cents: > >> - From a copyright perspective it should have been enough to check the licence file and name the contributors there > > > > > > But nobody uses the license file for that, usually there's only the original author(s) / main maintainer(s). That's why the (git) history is relevant. > > > >> > >> - The history could have been retrieved in a separate branch and then merged (and look, we had the best of the two worlds!) > >> > >> - both of the things could have been then integrated through a pull request (luckily in less than one hour :)) > > > > > > Yep. > > > >> > >> And at the end, with the apport of everybody we could have got a repository with history, baseline and working on pharo 7. > >> > >> Now, from a human perspective, please let's try everybody to assume the best of the other by default. > >> That will just make all interactions much more healthy. > >> > >> And please, this is not particularly directed to anybody, I've seen such remarks many times. Let's just think positive. > >> Problems can be fixed if we talk about them, but more specifically if we are looking for solutions. > > > > > > I will see how I can streamline the tool even further... maybe a service that will migrate entire smalltalkhub :) > > > > Peter

Sept. 30, 2018

Re: [Pharo-dev] Reach of Iceberg/git/tonel ?

by Stephane Ducasse

Tx esteban The situation is better than I thought. Near perfect in fact! Well done. Now I think that as a community we should deprecate mcz packages. This is why we should migrate our projects to git and tonel. S. On Sun, Sep 30, 2018 at 11:01 AM Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > > Hi, > > > > > > On 29 Sep 2018, at 14:39, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > > > > Hi, > > > > So the future for Pharo is Iceberg/git/tonel and that is fine. > > > > My question however is: if I convert my external libraries to this new format, what is the reach of this new technology ? Can people still load code in older versions of Pharo ? I think 6.x is no problem, but what about earlier versions ? What about other Smalltalk implementations ? What is the official answer here ? > > In absence of Iceberg, Tonel can be used as any other MCRepository. You can save and read your packages as it would be with a âmetadataless filetreeâ. > That means, in Pharo without iceberg you need to save/read from your cloned repository. > Saving to your cloned repository will write files to disk. Which means you need to go there and do a regular git commit/push cycle. > > While this is annoying compared with the usage of Iceberg, is perfectly doable: it is the same as while using metadataless filetree. > > Tonel is tested to work up to Pharo 3. Older Pharos may work (there is no reason why not) but maybe some minor adjustments are needed. > > I designed Tonel to be easily portable. I didnât used a lot of Pharo elements that would have done my life a lot easier (like using RBParser instead parsing manual). This way other dialects can take it and make it work. Now, making it work, is a problem of other dialects users (Iâm willing to help, but that work will fall in other persons). > I know it is already ported to Gemstone and it was being ported to Squeak. > > > A second question: suppose a repo is converted, is then still possible to copy a version over to an old MC repo ? Just to keep it in sync. > > You can save your packages as you want. > You can save a package with Iceberg and then read it with Monticello., > And viceversa. > Now, it you want to "transferâ the history from git to an mcz, you will need to do some migration tool. > > Esteban > > > > > Thx, > > > > Sven > > > > > >

Sept. 30, 2018

Re: [Pharo-dev] Reach of Iceberg/git/tonel ?

by Esteban Lorenzano

Hi, > On 29 Sep 2018, at 14:39, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > > Hi, > > So the future for Pharo is Iceberg/git/tonel and that is fine. > > My question however is: if I convert my external libraries to this new format, what is the reach of this new technology ? Can people still load code in older versions of Pharo ? I think 6.x is no problem, but what about earlier versions ? What about other Smalltalk implementations ? What is the official answer here ? In absence of Iceberg, Tonel can be used as any other MCRepository. You can save and read your packages as it would be with a âmetadataless filetreeâ. That means, in Pharo without iceberg you need to save/read from your cloned repository. Saving to your cloned repository will write files to disk. Which means you need to go there and do a regular git commit/push cycle. While this is annoying compared with the usage of Iceberg, is perfectly doable: it is the same as while using metadataless filetree. Tonel is tested to work up to Pharo 3. Older Pharos may work (there is no reason why not) but maybe some minor adjustments are needed. I designed Tonel to be easily portable. I didnât used a lot of Pharo elements that would have done my life a lot easier (like using RBParser instead parsing manual). This way other dialects can take it and make it work. Now, making it work, is a problem of other dialects users (Iâm willing to help, but that work will fall in other persons). I know it is already ported to Gemstone and it was being ported to Squeak. > A second question: suppose a repo is converted, is then still possible to copy a version over to an old MC repo ? Just to keep it in sync. You can save your packages as you want. You can save a package with Iceberg and then read it with Monticello., And viceversa. Now, it you want to "transferâ the history from git to an mcz, you will need to do some migration tool. Esteban > > Thx, > > Sven > >

Sept. 30, 2018

Re: [Pharo-dev] Reach of Iceberg/git/tonel ?

by Gabriel Cotelli

I don't know if something changed with tonel support but with filetree if you copy a package into a Monticello repo it get converted to mcz. So I think you can have a copy of each release in a Monticello repo if you want. On Sat, Sep 29, 2018, 09:40 Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > Hi, > > So the future for Pharo is Iceberg/git/tonel and that is fine. > > My question however is: if I convert my external libraries to this new > format, what is the reach of this new technology ? Can people still load > code in older versions of Pharo ? I think 6.x is no problem, but what about > earlier versions ? What about other Smalltalk implementations ? What is the > official answer here ? > > A second question: suppose a repo is converted, is then still possible to > copy a version over to an old MC repo ? Just to keep it in sync. > > Thx, > > Sven > > >

Sept. 29, 2018

Re: [Pharo-dev] Reach of Iceberg/git/tonel ?

by Stephane Ducasse

Hi Sven > So the future for Pharo is Iceberg/git/tonel and that is fine. I'm waiting for Tonel since 2002. I should have done it. Now what was blocking me stupidly was that I wanted to have a support for Snippets (doit) and this was more in that sense a scripting syntax biais. This format will give to all the community a lot of exposure. > My question however is: if I convert my external libraries to this new format, what is the reach of this new technology ? Everybody in the world will be able to read your code. Which is not the case right now. > Can people still load code in older versions of Pharo ? I think 6.x is no problem, but what about earlier versions ? I do not know. Loading a new version in an old system is always a challenge because some libraries will improve. Now if they pay us for that we can do something. Can I latex my papers about 5 years ago, clearly not. Can I run my old app on my new iphone not really. So if this is not working for paid software why should it be for free one? > What about other Smalltalk implementations ? What is the official answer here ? They are lucky Tonel is MIT and we are not against them. I would not expect other people would expect that they port freely their code to Pharo without me giving a hand. So the inverse is true. > A second question: suppose a repo is converted, is then still possible to copy a version over to an old MC repo ? No this is not possible with filetree and I do not see why it would be possible for Tonel > Just to keep it in sync. I do not know. May be somehow with time and energy can do it. One could hack MC to include Tonel inside. Now I think that there are many other things to do. Iceberg is using some part of MC now do not expect our engineers to do this for free. After people will complain that they do not work on the real value. > > Thx, > > Sven > >

Sept. 29, 2018

Re: [Pharo-dev] [ANN] Migrated Artefact to GitHub

by Stephane Ducasse

Hi Peter Just a note to say that I appretiate your attitude and we know it each other. I will try to use your tool when I will migrate my projects. Stef On Sat, Sep 29, 2018 at 2:32 PM Peter Uhnak <i.uhnak(a)gmail.com> wrote: >> >> - you're stealing > > > Sorry, I absolutely did not intend the evoke the notion of "stealing". > My perspective is... I am spending time to migrate someone else's code, so the last thing I want is someone burning my energy and complaining that I voided their contribution. > > I don't give a fuck if someone migrates my contribution and strips the authorship (and when I do care I don't need to rely on others to prove it). > But I want to cover my ass from backlash from other people, because I know it will happen and I know that people will complain (which is exactly what happened to you). > > So preventing the appropriation of code is not about you taking credit for other person's code, but you being covered from them accusing you of it. (It probably sounds like I am pathologically defensive, but dealing with people is exhausting for me.) > >> >>> * it is sending bad signals to potential contributors that we can scrub them anytime we want >>> >>> as you yourself have said: >>> > @People try to avoid to piss on good will of others. >>> Yet this is what it feels like to some when traces of their contributions are voided. >> >> >> And this is my third point. This "stealing" idea is mainly a matter of manners. > > > Again, I didn't intend "stealing". It's about preventing people from thinking "They don't give a fuck about their contributors, so why I should give a fuck about contributing?". It can be dispiriting for them, even if they don't care about the code itself. And they will complain... and who needs that? > >> If instead of bashing on people, we wanted to discuss on how to actually FIX the thing, here are my 2 cents: >> - From a copyright perspective it should have been enough to check the licence file and name the contributors there > > > But nobody uses the license file for that, usually there's only the original author(s) / main maintainer(s). That's why the (git) history is relevant. > >> >> - The history could have been retrieved in a separate branch and then merged (and look, we had the best of the two worlds!) >> >> - both of the things could have been then integrated through a pull request (luckily in less than one hour :)) > > > Yep. > >> >> And at the end, with the apport of everybody we could have got a repository with history, baseline and working on pharo 7. >> >> Now, from a human perspective, please let's try everybody to assume the best of the other by default. >> That will just make all interactions much more healthy. >> >> And please, this is not particularly directed to anybody, I've seen such remarks many times. Let's just think positive. >> Problems can be fixed if we talk about them, but more specifically if we are looking for solutions. > > > I will see how I can streamline the tool even further... maybe a service that will migrate entire smalltalkhub :) > > Peter

Sept. 29, 2018

Re: [Pharo-dev] Reach of Iceberg/git/tonel ?

by Ben Coman

On Sat, 29 Sep 2018 at 20:40, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > Hi, > > So the future for Pharo is Iceberg/git/tonel and that is fine. > > My question however is: if I convert my external libraries to this new > format, what is the reach of this new technology ? Can people still load > code in older versions of Pharo ? I think 6.x is no problem, but what about > earlier versions ? What about other Smalltalk implementations ? What is the > official answer here ? > > A second question: suppose a repo is converted, is then still possible to > copy a version over to an old MC repo ? Just to keep it in sync. > Just to throw an idea into the mix, perhaps a read-only option for older Pharo and alternate Smalltalk implementations is to use ZIP downloads from github. https://github.com/svenvc/ston/archive/master.zip There would still be a requirement to parse Tonel, but that might be a smaller mission than supporting Iceberg or other full-Git implementation. A Metacello baseline might bootstrap Tonel to parse the unzipped file. cheers -ben

Sept. 29, 2018

Re: [Pharo-dev] Reach of Iceberg/git/tonel ?

by Peter Uhnak

Hi, Can people still load code in older versions of Pharo ? I think 6.x is no > problem, but what about earlier versions ? You will need to update Metacello in older versions of Pharo to use Tonel. But Pharo <6.1 is officially not supported anyway. > What about other Smalltalk implementations ? What is the official answer > here ? > If they use Metacello, then you should be able to use Tonel. A second question: suppose a repo is converted, is then still possible to > copy a version over to an old MC repo ? Just to keep it in sync. > As long as Iceberg uses internally a Metacello repository for Tonel, you should be able to copy a _snapshot_. If you want to keep a "in sync" history with ancestry and stuff, then I would advise against it. The history model is quite different between git and MC and you need to make compromises going in each direction. Peter

Sept. 29, 2018

Reach of Iceberg/git/tonel ?

by Sven Van Caekenberghe

Hi, So the future for Pharo is Iceberg/git/tonel and that is fine. My question however is: if I convert my external libraries to this new format, what is the reach of this new technology ? Can people still load code in older versions of Pharo ? I think 6.x is no problem, but what about earlier versions ? What about other Smalltalk implementations ? What is the official answer here ? A second question: suppose a repo is converted, is then still possible to copy a version over to an old MC repo ? Just to keep it in sync. Thx, Sven

Sept. 29, 2018

Re: [Pharo-dev] [ANN] Migrated Artefact to GitHub

by Peter Uhnak

> > - you're stealing > Sorry, I absolutely did not intend the evoke the notion of "stealing". My perspective is... I am spending time to migrate someone else's code, so the last thing I want is someone burning my energy and complaining that I voided their contribution. I don't give a fuck if someone migrates my contribution and strips the authorship (and when I do care I don't need to rely on others to prove it). But I want to cover my ass from backlash from other people, because I know it will happen and I know that people will complain (which is exactly what happened to you). So preventing the appropriation of code is not about you taking credit for other person's code, but you being covered from them accusing you of it. (It probably sounds like I am pathologically defensive, but dealing with people is exhausting for me.) > * it is sending bad signals to potential contributors that we can scrub >> them anytime we want >> >> as you yourself have said: >> > @People try to avoid to piss on good will of others. >> Yet this is what it feels like to some when traces of their contributions >> are voided. >> > > And this is my third point. This "stealing" idea is mainly a matter of > manners. > Again, I didn't intend "stealing". It's about preventing people from thinking "They don't give a fuck about their contributors, so why I should give a fuck about contributing?". It can be dispiriting for them, even if they don't care about the code itself. And they will complain... and who needs that? If instead of bashing on people, we wanted to discuss on how to actually > FIX the thing, here are my 2 cents: > - From a copyright perspective it should have been enough to check the > licence file and name the contributors there > But nobody uses the license file for that, usually there's only the original author(s) / main maintainer(s). That's why the (git) history is relevant. > - The history could have been retrieved in a separate branch and then > merged (and look, we had the best of the two worlds!) > - both of the things could have been then integrated through a pull > request (luckily in less than one hour :)) > Yep. > And at the end, with the apport of everybody we could have got a > repository with history, baseline and working on pharo 7. > > Now, from a human perspective, please let's try everybody to assume the > best of the other by default. > That will just make all interactions much more healthy. > > And please, this is not particularly directed to anybody, I've seen such > remarks many times. Let's just think positive. > Problems can be fixed if we talk about them, but more specifically if we > are looking for solutions. > I will see how I can streamline the tool even further... maybe a service that will migrate entire smalltalkhub :) Peter

Sept. 29, 2018

Re: [Pharo-dev] [ANN] Migrated Artefact to GitHub

by Guillermo Polito

On Sat, Sep 29, 2018 at 12:41 PM Peter Uhnak <i.uhnak(a)gmail.com> wrote: > Hi Stef, > > I understand that everyone is short on time, but I consider not preserving > the history problematic for two reasons > > * it is appropriating someone else's work as one's own -- this seems > borderline illegal, or at the very least in violation of MIT license > Not really. If the contributors are specified in the copyright, is it stealing? Now, my point is manners. I got in 4/5 emails: - you're stupid because you did not use Peter's tool - you're inefficient because you took one hour to do it - you're stealing The first two points show first one big problem that I've seem many times with people and software: missing context. People think most of the time that "I would have done it better". But usually they don't take into account - the time constraints (I had one hour, and one hour I had) - the knowledge (where is the Artefact Repo?, why is it failing for Milton?, Do I know enough about metacello/streams/artefact to do it well?) - the working environment (does the person that did it have all the tools to work properly? does he have a healthy working environment? For example, I've worked on several big companies where you can find really bad environments...) - technical and not technical problems that are sometimes independent of the problem itself (take into account that for example, fighting against a metacello baseline is completely orthogonal to your tool or even iceberg, good internet connection) All these details are important also at the end, and they should be put into the balance too when we make a judgement. > * it is sending bad signals to potential contributors that we can scrub > them anytime we want > > as you yourself have said: > > @People try to avoid to piss on good will of others. > Yet this is what it feels like to some when traces of their contributions > are voided. > And this is my third point. This "stealing" idea is mainly a matter of manners. I really hope nobody here really thinks I wanted to take credit for Olivier, Guillaume or any of the other contributors. Still I preserved pointers to the original authors and their original website in google sites. But in the case somebody did think that, I removed the repository to remove any doubt. So again, I apologize if somebody felt offended, but I also prefer to not be called a thief. Now, when I do stuff I'm not thinking about "oh yes, I'm getting famous", that would be pretty sad for me :/. I do stuff because I just think it's useful. I DON'T CARE personally about artefact, and I don't want to take credit for it. I don't even care about the fu***ng 2 commits I did to port it to Pharo 7, I can tell anybody what I did so she/he can re-doit. Because I don't use Artefact. Now, Somebody wants the "credit"? I could have even amended a commit and put anybody else as author. My problem here is people assuming stealing by default, instead of assuming, for example, mistake. Imagine an alternative scenario: - X: "Hey Guille, could you add in the copyright X, and Y and Z? They also contributed to the project, you should take them into account..." - Guille: "Ah sure, sorry, this was not my intention, I'm so stupid, I forgot about Z. Commit push, done". If instead of bashing on people, we wanted to discuss on how to actually FIX the thing, here are my 2 cents: - From a copyright perspective it should have been enough to check the licence file and name the contributors there - The history could have been retrieved in a separate branch and then merged (and look, we had the best of the two worlds!) - both of the things could have been then integrated through a pull request (luckily in less than one hour :)) And at the end, with the apport of everybody we could have got a repository with history, baseline and working on pharo 7. Now, from a human perspective, please let's try everybody to assume the best of the other by default. That will just make all interactions much more healthy. And please, this is not particularly directed to anybody, I've seen such remarks many times. Let's just think positive. Problems can be fixed if we talk about them, but more specifically if we are looking for solutions.

Sept. 29, 2018

Re: [Pharo-dev] [ANN] Migrated Artefact to GitHub

by Peter Uhnak

Hi Stef, > You see you won. I was NOT one of the people responding or pushing Guille. And I don't consider Artifact not on github and people on both sides upset as winning... > Peter when I say that I do not have time, I really mean it. That's why I try offer people help with the migration whenever possible -- it is usually easy and fast for me to do, as I already know what I am doing. Peter On Sat, Sep 29, 2018 at 12:49 PM Stephane Ducasse <stepharo.self(a)gmail.com> wrote: > My last point on it. > if the philosophy is "I do not care about my software, but you have to > do it" then do not count me in. > > Stef > > On Sat, Sep 29, 2018 at 12:47 PM Stephane Ducasse > <stepharo.self(a)gmail.com> wrote: > > > > You see you won. Guille removed its repo and I understand him. > > I will now count how many months it will take for having artefact > > working in P7. > > > > > > > > Peter when I say that I do not have time, I really mean it. I have two > > reports to write for end of september. > > Not counting that updated pharo by example could be build anymore and > > that we need it for the mooc starting > > 8th of october, not counting that we have 4 new people arriving in the > > team and many many other things. > > > > Stef > > On Sat, Sep 29, 2018 at 12:41 PM Peter Uhnak <i.uhnak(a)gmail.com> wrote: > > > > > > Hi Stef, > > > > > > I understand that everyone is short on time, but I consider not > preserving the history problematic for two reasons > > > > > > * it is appropriating someone else's work as one's own -- this seems > borderline illegal, or at the very least in violation of MIT license > > > * it is sending bad signals to potential contributors that we can > scrub them anytime we want > > > > > > as you yourself have said: > > > > @People try to avoid to piss on good will of others. > > > Yet this is what it feels like to some when traces of their > contributions are voided. > > > > > > I've invested a ton of time to alleviate this process as much as > possible, and I can tell you for a fact that people are _really_ happy that > the authorship is preserved. > > > Not to mention that the history itself is valuable if you know how to > use it (and I very regularly look when a particular piece of code was > written when debugging issues). > > > > > > That being said, if you have issues with migrating or think that it > can be streamlined even further, > > > please let me know and I'd be happy to help you or streamline the tool > even further. > > > > > > Peter > > > > > > On Sat, Sep 29, 2018 at 10:23 AM Stephane Ducasse < > stepharo.self(a)gmail.com> wrote: > > >> > > >> Hi guille > > >> > > >> I deeply appreciated that you spent your time to bring Artefact to > Pharo 70 > > >> and in general all the positive energy you put around Pharo. > > >> I love Iceberg! and more! > > >> > > >> I quit these mailing-lists in the past because of these little > > >> aggressions, the "You should do that" > > >> I registered today again to this mailing list just to publicly talk to > > >> you, while I could come to your office (I will do it too). > > >> > > >> I did a port of Artefact to Pharo 60 a while ago and started to fix > > >> Artefact aspects I did not like and I would like to integrate my fixes > > >> to yours. Please let me know where it is. :) > > >> > > >> I do not care of the history because I prefer the future. If people > > >> care then this is their duties. Easy. If they are not happy. This is > > >> THEIR PROBLEM. You see people often tells me that I cannot control and > > >> that github is decentralised. It is! So enjoy but @People try to avoid > > >> to piss on good will of others. > > >> > > >> Now sorry Norbert your point that Guillemo would be rude because he > spent > > >> his time to help Milton and made sure that Artefact in Pharo 70 is > clearly > > >> out of context and misplaced. You see I did the same in > > >> github.com/olivierauverlot because I needed it. And this is like > that. > > >> Period. > > >> You are not happy. This is ok. You do not like it. This is ok too. > > >> > > >> This is several times that I noticed that your are not nice with > > >> emails so do the same than me: think about the impact on others. You > > >> have no idea about what guille is doing and what it is paid for and > > >> this is certainly not to fix Artefact. And you may notice that we know > > >> what is to work on others unmaintained code because we do it all the > > >> time, we even create documentation on systems we do not understand > > >> because some people are too busy to write method and class comments so > > >> imagine documentation. > > >> > > >> So I would like to thanks again guille and I would like to have > > >> artefact on Pharo 70. > > >> > > >> Stef > > >> > >

Sept. 29, 2018

Re: [Pharo-dev] [ANN] Migrated Artefact to GitHub

by Stephane Ducasse

My last point on it. if the philosophy is "I do not care about my software, but you have to do it" then do not count me in. Stef On Sat, Sep 29, 2018 at 12:47 PM Stephane Ducasse <stepharo.self(a)gmail.com> wrote: > > You see you won. Guille removed its repo and I understand him. > I will now count how many months it will take for having artefact > working in P7. > > > > Peter when I say that I do not have time, I really mean it. I have two > reports to write for end of september. > Not counting that updated pharo by example could be build anymore and > that we need it for the mooc starting > 8th of october, not counting that we have 4 new people arriving in the > team and many many other things. > > Stef > On Sat, Sep 29, 2018 at 12:41 PM Peter Uhnak <i.uhnak(a)gmail.com> wrote: > > > > Hi Stef, > > > > I understand that everyone is short on time, but I consider not preserving the history problematic for two reasons > > > > * it is appropriating someone else's work as one's own -- this seems borderline illegal, or at the very least in violation of MIT license > > * it is sending bad signals to potential contributors that we can scrub them anytime we want > > > > as you yourself have said: > > > @People try to avoid to piss on good will of others. > > Yet this is what it feels like to some when traces of their contributions are voided. > > > > I've invested a ton of time to alleviate this process as much as possible, and I can tell you for a fact that people are _really_ happy that the authorship is preserved. > > Not to mention that the history itself is valuable if you know how to use it (and I very regularly look when a particular piece of code was written when debugging issues). > > > > That being said, if you have issues with migrating or think that it can be streamlined even further, > > please let me know and I'd be happy to help you or streamline the tool even further. > > > > Peter > > > > On Sat, Sep 29, 2018 at 10:23 AM Stephane Ducasse <stepharo.self(a)gmail.com> wrote: > >> > >> Hi guille > >> > >> I deeply appreciated that you spent your time to bring Artefact to Pharo 70 > >> and in general all the positive energy you put around Pharo. > >> I love Iceberg! and more! > >> > >> I quit these mailing-lists in the past because of these little > >> aggressions, the "You should do that" > >> I registered today again to this mailing list just to publicly talk to > >> you, while I could come to your office (I will do it too). > >> > >> I did a port of Artefact to Pharo 60 a while ago and started to fix > >> Artefact aspects I did not like and I would like to integrate my fixes > >> to yours. Please let me know where it is. :) > >> > >> I do not care of the history because I prefer the future. If people > >> care then this is their duties. Easy. If they are not happy. This is > >> THEIR PROBLEM. You see people often tells me that I cannot control and > >> that github is decentralised. It is! So enjoy but @People try to avoid > >> to piss on good will of others. > >> > >> Now sorry Norbert your point that Guillemo would be rude because he spent > >> his time to help Milton and made sure that Artefact in Pharo 70 is clearly > >> out of context and misplaced. You see I did the same in > >> github.com/olivierauverlot because I needed it. And this is like that. > >> Period. > >> You are not happy. This is ok. You do not like it. This is ok too. > >> > >> This is several times that I noticed that your are not nice with > >> emails so do the same than me: think about the impact on others. You > >> have no idea about what guille is doing and what it is paid for and > >> this is certainly not to fix Artefact. And you may notice that we know > >> what is to work on others unmaintained code because we do it all the > >> time, we even create documentation on systems we do not understand > >> because some people are too busy to write method and class comments so > >> imagine documentation. > >> > >> So I would like to thanks again guille and I would like to have > >> artefact on Pharo 70. > >> > >> Stef > >>

Sept. 29, 2018

Re: [Pharo-dev] [ANN] Migrated Artefact to GitHub

by Stephane Ducasse

You see you won. Guille removed its repo and I understand him. I will now count how many months it will take for having artefact working in P7. Peter when I say that I do not have time, I really mean it. I have two reports to write for end of september. Not counting that updated pharo by example could be build anymore and that we need it for the mooc starting 8th of october, not counting that we have 4 new people arriving in the team and many many other things. Stef On Sat, Sep 29, 2018 at 12:41 PM Peter Uhnak <i.uhnak(a)gmail.com> wrote: > > Hi Stef, > > I understand that everyone is short on time, but I consider not preserving the history problematic for two reasons > > * it is appropriating someone else's work as one's own -- this seems borderline illegal, or at the very least in violation of MIT license > * it is sending bad signals to potential contributors that we can scrub them anytime we want > > as you yourself have said: > > @People try to avoid to piss on good will of others. > Yet this is what it feels like to some when traces of their contributions are voided. > > I've invested a ton of time to alleviate this process as much as possible, and I can tell you for a fact that people are _really_ happy that the authorship is preserved. > Not to mention that the history itself is valuable if you know how to use it (and I very regularly look when a particular piece of code was written when debugging issues). > > That being said, if you have issues with migrating or think that it can be streamlined even further, > please let me know and I'd be happy to help you or streamline the tool even further. > > Peter > > On Sat, Sep 29, 2018 at 10:23 AM Stephane Ducasse <stepharo.self(a)gmail.com> wrote: >> >> Hi guille >> >> I deeply appreciated that you spent your time to bring Artefact to Pharo 70 >> and in general all the positive energy you put around Pharo. >> I love Iceberg! and more! >> >> I quit these mailing-lists in the past because of these little >> aggressions, the "You should do that" >> I registered today again to this mailing list just to publicly talk to >> you, while I could come to your office (I will do it too). >> >> I did a port of Artefact to Pharo 60 a while ago and started to fix >> Artefact aspects I did not like and I would like to integrate my fixes >> to yours. Please let me know where it is. :) >> >> I do not care of the history because I prefer the future. If people >> care then this is their duties. Easy. If they are not happy. This is >> THEIR PROBLEM. You see people often tells me that I cannot control and >> that github is decentralised. It is! So enjoy but @People try to avoid >> to piss on good will of others. >> >> Now sorry Norbert your point that Guillemo would be rude because he spent >> his time to help Milton and made sure that Artefact in Pharo 70 is clearly >> out of context and misplaced. You see I did the same in >> github.com/olivierauverlot because I needed it. And this is like that. >> Period. >> You are not happy. This is ok. You do not like it. This is ok too. >> >> This is several times that I noticed that your are not nice with >> emails so do the same than me: think about the impact on others. You >> have no idea about what guille is doing and what it is paid for and >> this is certainly not to fix Artefact. And you may notice that we know >> what is to work on others unmaintained code because we do it all the >> time, we even create documentation on systems we do not understand >> because some people are too busy to write method and class comments so >> imagine documentation. >> >> So I would like to thanks again guille and I would like to have >> artefact on Pharo 70. >> >> Stef >>

Sept. 29, 2018

Re: [Pharo-dev] Migrating XML support to github/PharoContributions/

by Stephane Ducasse

Please it would be super nice. Once this is done, I would like to update the scraping booklet to use github version. Stef On Sat, Sep 29, 2018 at 12:19 PM Peter Uhnak <i.uhnak(a)gmail.com> wrote: > > Hi Stef, > > XMLParser is maintained by monty (I've CCed him). > > > Now the question still remains: who is planning to migrate the XML packages. > > I'd be happy to do that (including preserving the history), unless monty wants to do it themselves. > > Peter > > On Sat, Sep 29, 2018 at 10:39 AM Stephane Ducasse <stepharo.self(a)gmail.com> wrote: >> >> Hi >> >> I contacted the maintainer (but I'm not sure in fact who it is :) ) >> about the XML related packages in Pharo extras. >> >> XMLParser >> XMLParserHTML >> XMLParserStAX >> XMLSupport >> XMLWriter >> XPath >> >> I did not get any answer so may be I sent a mail to the wrong email address. >> Probably. >> Now the question still remains: who is planning to migrate the XML packages. >> I was planning to do it but I will not consider history because I do >> not know how to do it and I do not have the time to do it (sorry). And >> yes I work the weekends and this is bad and this is not even on Pharo. >> >> I was planning to spend some time on the baseline and making sure that >> we can load everything and run the tests. >> So let me know. >> >> Stef >>

Sept. 29, 2018

Re: [Pharo-dev] Migrating XML support to github/PharoContributions/

by Stephane Ducasse

Hi Sven SmalltalkHub is dying. And we will turn it readonly by January. Esteban has something else to do that to take care of it. It is a legacy. We are about to announce that we cannot create account and projects anymore. We are waiting to do that after the mooc. Now you want to use Squeaksource or SS3 I do not want. I want to use github and I guess that I do not have to explain why for real. Stef On Sat, Sep 29, 2018 at 11:27 AM Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > > I think that would be monty, email addresses (CC-ed) > > monty2(a)programmer.net > montykamath(a)gmail.com > > I should note that he has been very good at maintaining the XML packages (the specs of which are super complex), and as far as I know, the code works under Pharo 7 ... > > What does not work for you ? > > Sven > > > On 29 Sep 2018, at 10:38, Stephane Ducasse <stepharo.self(a)gmail.com> wrote: > > > > Hi > > > > I contacted the maintainer (but I'm not sure in fact who it is :) ) > > about the XML related packages in Pharo extras. > > > > XMLParser > > XMLParserHTML > > XMLParserStAX > > XMLSupport > > XMLWriter > > XPath > > > > I did not get any answer so may be I sent a mail to the wrong email address. > > Probably. > > Now the question still remains: who is planning to migrate the XML packages. > > I was planning to do it but I will not consider history because I do > > not know how to do it and I do not have the time to do it (sorry). And > > yes I work the weekends and this is bad and this is not even on Pharo. > > > > I was planning to spend some time on the baseline and making sure that > > we can load everything and run the tests. > > So let me know. > > > > Stef > > > >

Sept. 29, 2018

Re: [Pharo-dev] [ANN] Migrated Artefact to GitHub

by Peter Uhnak

Hi Stef, I understand that everyone is short on time, but I consider not preserving the history problematic for two reasons * it is appropriating someone else's work as one's own -- this seems borderline illegal, or at the very least in violation of MIT license * it is sending bad signals to potential contributors that we can scrub them anytime we want as you yourself have said: > @People try to avoid to piss on good will of others. Yet this is what it feels like to some when traces of their contributions are voided. I've invested a ton of time to alleviate this process as much as possible, and I can tell you for a fact that people are _really_ happy that the authorship is preserved. Not to mention that the history itself is valuable if you know how to use it (and I very regularly look when a particular piece of code was written when debugging issues). That being said, if you have issues with migrating or think that it can be streamlined even further, please let me know and I'd be happy to help you or streamline the tool even further. Peter On Sat, Sep 29, 2018 at 10:23 AM Stephane Ducasse <stepharo.self(a)gmail.com> wrote: > Hi guille > > I deeply appreciated that you spent your time to bring Artefact to Pharo 70 > and in general all the positive energy you put around Pharo. > I love Iceberg! and more! > > I quit these mailing-lists in the past because of these little > aggressions, the "You should do that" > I registered today again to this mailing list just to publicly talk to > you, while I could come to your office (I will do it too). > > I did a port of Artefact to Pharo 60 a while ago and started to fix > Artefact aspects I did not like and I would like to integrate my fixes > to yours. Please let me know where it is. :) > > I do not care of the history because I prefer the future. If people > care then this is their duties. Easy. If they are not happy. This is > THEIR PROBLEM. You see people often tells me that I cannot control and > that github is decentralised. It is! So enjoy but @People try to avoid > to piss on good will of others. > > Now sorry Norbert your point that Guillemo would be rude because he spent > his time to help Milton and made sure that Artefact in Pharo 70 is clearly > out of context and misplaced. You see I did the same in > github.com/olivierauverlot because I needed it. And this is like that. > Period. > You are not happy. This is ok. You do not like it. This is ok too. > > This is several times that I noticed that your are not nice with > emails so do the same than me: think about the impact on others. You > have no idea about what guille is doing and what it is paid for and > this is certainly not to fix Artefact. And you may notice that we know > what is to work on others unmaintained code because we do it all the > time, we even create documentation on systems we do not understand > because some people are too busy to write method and class comments so > imagine documentation. > > So I would like to thanks again guille and I would like to have > artefact on Pharo 70. > > Stef > >

Sept. 29, 2018

Re: [Pharo-dev] Migrating XML support to github/PharoContributions/

by Peter Uhnak

Hi Stef, XMLParser is maintained by monty (I've CCed him). > Now the question still remains: who is planning to migrate the XML packages. I'd be happy to do that (including preserving the history), unless monty wants to do it themselves. Peter On Sat, Sep 29, 2018 at 10:39 AM Stephane Ducasse <stepharo.self(a)gmail.com> wrote: > Hi > > I contacted the maintainer (but I'm not sure in fact who it is :) ) > about the XML related packages in Pharo extras. > > XMLParser > XMLParserHTML > XMLParserStAX > XMLSupport > XMLWriter > XPath > > I did not get any answer so may be I sent a mail to the wrong email > address. > Probably. > Now the question still remains: who is planning to migrate the XML > packages. > I was planning to do it but I will not consider history because I do > not know how to do it and I do not have the time to do it (sorry). And > yes I work the weekends and this is bad and this is not even on Pharo. > > I was planning to spend some time on the baseline and making sure that > we can load everything and run the tests. > So let me know. > > Stef > >

Sept. 29, 2018

[Pharo 7.0-dev] Build #1278: 22397-Add-executable-comments-to-Date-classes

by ci-pharo-ci-jenkins2＠inria.fr

There is a new Pharo build available! The status of the build #1278 was: SUCCESS. The Pull Request #1832 was integrated: "22397-Add-executable-comments-to-Date-classes" Pull request url: https://github.com/pharo-project/pharo/pull/1832 Issue Url: https://pharo.fogbugz.com/f/cases/22397 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Sept. 29, 2018

Re: [Pharo-dev] Migrating XML support to github/PharoContributions/

by Sven Van Caekenberghe

I think that would be monty, email addresses (CC-ed) monty2(a)programmer.net montykamath(a)gmail.com I should note that he has been very good at maintaining the XML packages (the specs of which are super complex), and as far as I know, the code works under Pharo 7 ... What does not work for you ? Sven > On 29 Sep 2018, at 10:38, Stephane Ducasse <stepharo.self(a)gmail.com> wrote: > > Hi > > I contacted the maintainer (but I'm not sure in fact who it is :) ) > about the XML related packages in Pharo extras. > > XMLParser > XMLParserHTML > XMLParserStAX > XMLSupport > XMLWriter > XPath > > I did not get any answer so may be I sent a mail to the wrong email address. > Probably. > Now the question still remains: who is planning to migrate the XML packages. > I was planning to do it but I will not consider history because I do > not know how to do it and I do not have the time to do it (sorry). And > yes I work the weekends and this is bad and this is not even on Pharo. > > I was planning to spend some time on the baseline and making sure that > we can load everything and run the tests. > So let me know. > > Stef >

Sept. 29, 2018

[Pharo 7.0-dev] Build #1277: 22497-MIMEDocumentsaveToFile-should-not-use-FileStream

by ci-pharo-ci-jenkins2＠inria.fr

There is a new Pharo build available! The status of the build #1277 was: SUCCESS. The Pull Request #1838 was integrated: "22497-MIMEDocumentsaveToFile-should-not-use-FileStream" Pull request url: https://github.com/pharo-project/pharo/pull/1838 Issue Url: https://pharo.fogbugz.com/f/cases/22497 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Sept. 29, 2018

Migrating XML support to github/PharoContributions/

by Stephane Ducasse

Hi I contacted the maintainer (but I'm not sure in fact who it is :) ) about the XML related packages in Pharo extras. XMLParser XMLParserHTML XMLParserStAX XMLSupport XMLWriter XPath I did not get any answer so may be I sent a mail to the wrong email address. Probably. Now the question still remains: who is planning to migrate the XML packages. I was planning to do it but I will not consider history because I do not know how to do it and I do not have the time to do it (sorry). And yes I work the weekends and this is bad and this is not even on Pharo. I was planning to spend some time on the baseline and making sure that we can load everything and run the tests. So let me know. Stef

Sept. 29, 2018

[ANN] Migrated Artefact to GitHub

by Stephane Ducasse

Hi guille I deeply appreciated that you spent your time to bring Artefact to Pharo 70 and in general all the positive energy you put around Pharo. I love Iceberg! and more! I quit these mailing-lists in the past because of these little aggressions, the "You should do that" I registered today again to this mailing list just to publicly talk to you, while I could come to your office (I will do it too). I did a port of Artefact to Pharo 60 a while ago and started to fix Artefact aspects I did not like and I would like to integrate my fixes to yours. Please let me know where it is. :) I do not care of the history because I prefer the future. If people care then this is their duties. Easy. If they are not happy. This is THEIR PROBLEM. You see people often tells me that I cannot control and that github is decentralised. It is! So enjoy but @People try to avoid to piss on good will of others. Now sorry Norbert your point that Guillemo would be rude because he spent his time to help Milton and made sure that Artefact in Pharo 70 is clearly out of context and misplaced. You see I did the same in github.com/olivierauverlot because I needed it. And this is like that. Period. You are not happy. This is ok. You do not like it. This is ok too. This is several times that I noticed that your are not nice with emails so do the same than me: think about the impact on others. You have no idea about what guille is doing and what it is paid for and this is certainly not to fix Artefact. And you may notice that we know what is to work on others unmaintained code because we do it all the time, we even create documentation on systems we do not understand because some people are too busy to write method and class comments so imagine documentation. So I would like to thanks again guille and I would like to have artefact on Pharo 70. Stef

Sept. 29, 2018

Re: [Pharo-dev] Artifact and PDFExporter for Roassal

by Alexandre Bergel

Thanks Guille! Alexandre > On Sep 27, 2018, at 7:27 PM, Guillermo Polito <guillermopolito(a)gmail.com> wrote: > > Hi Milton, > > I've taken 1 hour to migrate Artefact to Github, create a baseline, fix your issue and make a new release. > Can you test? > > https://github.com/pharo-contributions/Artefact > > Guille > > On Thu, Sep 13, 2018 at 4:40 PM milton mamani <akevalion(a)gmail.com> wrote: > > > El jue., 13 sept. 2018 a las 14:06, milton mamani (<akevalion(a)gmail.com>) escribiÃ³: > Hi! > > I am Milton Mamani I work with Roassal2, and now I am in ESUG-Cagliari, and I have tried to load Artefact with the next piece of code, in the last Pharo7 image. > > Metacello new > configuration: 'Artefact'; > smalltalkhubUser: 'RMoD' project: 'Artefact'; > version: #stable; > load. > > "To load roassal and pdf roassal exporter" > Metacello new > > > configuration: 'GraphQLBeta' > ; > > smalltalkhubUser: 'ObjectProfile' project: 'GraphQL' > ; > > version: #development > ; > load. > > Gofer new > smalltalkhubUser: 'azazael' project: 'RTPDFExporter'; > package: 'ConfigurationOfRTPDFExporter'; load. > (Smalltalk at: #ConfigurationOfRTPDFExporter) loadDevelopment > > I have a problem, when I tried to export my Roassal-Visualization to pdf file with for example this piece of code: > > view := RTBoxPlotExample new exampleBoxPlot5 build view. > stream := 'foo.pdf' asFileReference writeStream. > > [RTPDFExporter new > stream: stream; > exportView: view ] ensure: [ stream close ] > > I get a lot of kind exceptions related with the class: PDFStreamPrinter > > In the method visitPDFDataXRefEntry: > And in the logic of the new Stream classes of Pharo7. > > Could you please review Artifact in Pharo7 with this roassal2 implementation > > Cheers, > Milton > > > > -- > > Guille Polito > Research Engineer > > Centre de Recherche en Informatique, Signal et Automatique de Lille > CRIStAL - UMR 9189 > French National Center for Scientific Research - http://www.cnrs.fr > > Web: http://guillep.github.io > Phone: +33 06 52 70 66 13

Sept. 28, 2018

[Pharo 7.0-dev] Build #1276: 22482-AutoCompletion-preview-breaks-code-navigation

by ci-pharo-ci-jenkins2＠inria.fr

There is a new Pharo build available! The status of the build #1276 was: SUCCESS. The Pull Request #1831 was integrated: "22482-AutoCompletion-preview-breaks-code-navigation" Pull request url: https://github.com/pharo-project/pharo/pull/1831 Issue Url: https://pharo.fogbugz.com/f/cases/22482 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Sept. 28, 2018

[Pharo 7.0-dev] Build #1275: 22480-ClassTestCase--testClassComment-depends-on-the-environment-configuration

by ci-pharo-ci-jenkins2＠inria.fr

There is a new Pharo build available! The status of the build #1275 was: FAILURE. The Pull Request #1829 was integrated: "22480-ClassTestCase--testClassComment-depends-on-the-environment-configuration" Pull request url: https://github.com/pharo-project/pharo/pull/1829 Issue Url: https://pharo.fogbugz.com/f/cases/22480 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Sept. 28, 2018

[Pharo 7.0-dev] Build #1274: 22458-lastFileFor-baseFileName-extension-extension-randomly-sorts-files

by ci-pharo-ci-jenkins2＠inria.fr

There is a new Pharo build available! The status of the build #1274 was: FAILURE. The Pull Request #1806 was integrated: "22458-lastFileFor-baseFileName-extension-extension-randomly-sorts-files" Pull request url: https://github.com/pharo-project/pharo/pull/1806 Issue Url: https://pharo.fogbugz.com/f/cases/22458 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Sept. 28, 2018

Re: [Pharo-dev] PharoLauncher based test resporting centre

by Ben Coman

On Fri, 28 Sep 2018 at 10:23, Ben Coman <btc(a)openinworld.com> wrote: > Just a random idea... > when running Testrunner locally and a random test causes the image to > freeze, its a bit of an effort to identify which test was being run. You > need to restart and then start bisecting the tests and perhaps it is > intermittent so the bisect doesn't work... > > but now that PharoLauncher has been mainstreamed > maybe it could provide a centralised Reporting Centre > i.e. open a port for launched images to report the test about-to-commence > as well as the run time. Then it would be simple to see which test froze > the system. Also it could keep a record individual test runtimes, to > alleviate fears when the system is not frozen but just a long running test. > > Extending the idea, while CI testing is very useful, we get these sporadic > errors that are hard to replicate locally. A local PharoLauncher driven > system for repetitively launching an image auto-running tests might be good > to gather statistics on sporadic failures to then drill down on the > troublemakers. > > Plus with the goal of having an object based logging system, a viewer is > needed and perhaps PharoLauncher would be a logical place to provide a > logging service to gather and especially to view log-objects reporting by > launched images. > side thought, such a system might be good for watching test progress on headless IoT devices. > > of course, resources required to do it, > but just thought I share the idea. > > cheers -ben >

Sept. 28, 2018

PharoLauncher based test resporting centre

by Ben Coman

Just a random idea... when running Testrunner locally and a random test causes the image to freeze, its a bit of an effort to identify which test was being run. You need to restart and then start bisecting the tests and perhaps it is intermittent so the bisect doesn't work... but now that PharoLauncher has been mainstreamed maybe it could provide a centralised Reporting Centre i.e. open a port for launched images to report the test about-to-commence as well as the run time. Then it would be simple to see which test froze the system. Also it could keep a record individual test runtimes, to alleviate fears when the system is not frozen but just a long running test. Extending the idea, while CI testing is very useful, we get these sporadic errors that are hard to replicate locally. A local PharoLauncher driven system for repetitively launching an image auto-running tests might be good to gather statistics on sporadic failures to then drill down on the troublemakers. Plus with the goal of having an object based logging system, a viewer is needed and perhaps PharoLauncher would be a logical place to provide a logging service to gather and especially to view log-objects reporting by launched images. of course, resources required to do it, but just thought I share the idea. cheers -ben

Sept. 28, 2018

[Pharo 7.0-dev] Build #1273: 22477-DelayScheduler-cleanup-and-refactoring

by ci-pharo-ci-jenkins2＠inria.fr

There is a new Pharo build available! The status of the build #1273 was: FAILURE. The Pull Request #1819 was integrated: "22477-DelayScheduler-cleanup-and-refactoring" Pull request url: https://github.com/pharo-project/pharo/pull/1819 Issue Url: https://pharo.fogbugz.com/f/cases/22477 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Sept. 27, 2018

Re: [Pharo-dev] [Pharo-users] [ANN] Migrated Artefact to GitHub

by Alistair Grant

Hi Guille, I wasn't aware this existed - thanks for letting us know! Cheers, Alistair On Thu, 27 Sep 2018 at 15:41, Norbert Hartl <norbert(a)hartl.name> wrote: > > Super! Thanks > > Norbert > > Am 27.09.2018 um 11:26 schrieb Guillermo Polito <guillermopolito(a)gmail.com>: > > Hi all, > > I've moved the Artefact library to GitHub (https://github.com/pharo-contributions/Artefact) > > I've also made some changes to it in the way and made a 1.7.0 version with: > - support for Pharo7 streams > - a baseline > > So, people using Artifact, you can contribute through pull requests ^^, > Guille > > -- > > > > Guille Polito > > Research Engineer > > Centre de Recherche en Informatique, Signal et Automatique de Lille > > CRIStAL - UMR 9189 > > French National Center for Scientific Research - http://www.cnrs.fr > > > Web: http://guillep.github.io > > Phone: +33 06 52 70 66 13

Sept. 27, 2018

Re: [Pharo-dev] Esteban's ChangeLog week of 17 September 2018

by Sven Van Caekenberghe

> On 24 Sep 2018, at 10:01, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > > > >> On 24 Sep 2018, at 09:11, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: >> >> Esteban, >> >>> On 24 Sep 2018, at 08:00, estebanlm(a)gmail.com wrote: >>> >>> * I migrated all [pharo-ide](https://github.com/pharo-ide) projects to tonel format. >>> >>> Harder than it seems, it took me a good bunch of hours. But now is working. >>> >>> This will enhance work/fixes on Calypso. >> >> If it was hard for you, how are we supposed to do it ? >> Is there a guide/description somewhere ? > > For what? > Migration? > There is an option on iceberg (repository/extrasâ¦) that does that and it will work 99% of the cases (there is a known bug with a fix waiting on the iceberg repo who prevents seaside migration). > This will migrate without history. Or better: history will be there, just in filetree but since there is no match between one format and another and that will give problems to see the history. I managed to convert https://github.com/svenvc/P3 to Tonel and all went well (as far as I can see). I must say that Iceberg matured a lot lately, it works super nice. Thx! > The problem here was that I needed to migrate all pharo-ide repositories, and update baselines and make all tests pass and in the middle I exceeding travis ârightâ to see tags (if you are not authenticated, it can happen), etc. > So a lot of small problems not directly related with the migration itself :) > > Esteban > >> >> Sven

Sept. 27, 2018

Top MenuBar does not auto follow font changes

by Sven Van Caekenberghe

Hi, The Top MenuBar does not seem to auto follow font changes, although it picks them uppitiest when you hide/show the menu bar from the Settings. Sven

Sept. 27, 2018

Re: [Pharo-dev] [Pharo-users] [ANN] Migrated Artefact to GitHub

by Norbert Hartl

Super! Thanks Norbert > Am 27.09.2018 um 11:26 schrieb Guillermo Polito <guillermopolito(a)gmail.com>: > > Hi all, > > I've moved the Artefact library to GitHub (https://github.com/pharo-contributions/Artefact) > > I've also made some changes to it in the way and made a 1.7.0 version with: > - support for Pharo7 streams > - a baseline > > So, people using Artifact, you can contribute through pull requests ^^, > Guille > > -- > > Guille Polito > Research Engineer > Centre de Recherche en Informatique, Signal et Automatique de Lille > CRIStAL - UMR 9189 > French National Center for Scientific Research - http://www.cnrs.fr > > Web: http://guillep.github.io > Phone: +33 06 52 70 66 13

Sept. 27, 2018

Re: [Pharo-dev] Artifact and PDFExporter for Roassal

by Guillermo Polito

Hi Milton, I've taken 1 hour to migrate Artefact to Github, create a baseline, fix your issue and make a new release. Can you test? https://github.com/pharo-contributions/Artefact Guille On Thu, Sep 13, 2018 at 4:40 PM milton mamani <akevalion(a)gmail.com> wrote: > > > El jue., 13 sept. 2018 a las 14:06, milton mamani (<akevalion(a)gmail.com>) > escribiÃ³: > >> Hi! >> >> I am Milton Mamani I work with Roassal2, and now I am in ESUG-Cagliari, >> and I have tried to load Artefact with the next piece of code, in the last >> Pharo7 image. >> >> Metacello new >> configuration: 'Artefact'; >> smalltalkhubUser: 'RMoD' project: 'Artefact'; >> version: #stable; >> load. >> >> "To load roassal and pdf roassal exporter" >> >> Metacello new >> configuration: 'GraphQLBeta'; >> smalltalkhubUser: 'ObjectProfile' project: 'GraphQL'; >> version: #development; >> load. >> >> Gofer new >> smalltalkhubUser: 'azazael' project: 'RTPDFExporter'; >> package: 'ConfigurationOfRTPDFExporter'; load. >> (Smalltalk at: #ConfigurationOfRTPDFExporter) loadDevelopment >> >> I have a problem, when I tried to export my Roassal-Visualization to pdf >> file with for example this piece of code: >> >> view := RTBoxPlotExample new exampleBoxPlot5 build view. >> stream := 'foo.pdf' asFileReference writeStream. >> >> [RTPDFExporter new >> stream: stream; >> exportView: view ] ensure: [ stream close ] >> >> I get a lot of kind exceptions related with the class: PDFStreamPrinter >> >> In the method visitPDFDataXRefEntry: >> And in the logic of the new Stream classes of Pharo7. >> >> Could you please review Artifact in Pharo7 with this roassal2 >> implementation >> >> Cheers, >> Milton >> >> -- Guille Polito Research Engineer Centre de Recherche en Informatique, Signal et Automatique de Lille CRIStAL - UMR 9189 French National Center for Scientific Research - *http://www.cnrs.fr <http://www.cnrs.fr>* *Web:* *http://guillep.github.io* <http://guillep.github.io> *Phone: *+33 06 52 70 66 13

Sept. 27, 2018

[ANN] Migrated Artefact to GitHub

by Guillermo Polito

Hi all, I've moved the Artefact library to GitHub ( https://github.com/pharo-contributions/Artefact) I've also made some changes to it in the way and made a 1.7.0 version with: - support for Pharo7 streams - a baseline So, people using Artifact, you can contribute through pull requests ^^, Guille -- Guille Polito Research Engineer Centre de Recherche en Informatique, Signal et Automatique de Lille CRIStAL - UMR 9189 French National Center for Scientific Research - *http://www.cnrs.fr <http://www.cnrs.fr>* *Web:* *http://guillep.github.io* <http://guillep.github.io> *Phone: *+33 06 52 70 66 13

Sept. 27, 2018

[Pharo 7.0-dev] Build #1272: 22490-It-seems-that-openFileStreamwritable-is-dead-code

by ci-pharo-ci-jenkins2＠inria.fr

There is a new Pharo build available! The status of the build #1272 was: SUCCESS. The Pull Request #1827 was integrated: "22490-It-seems-that-openFileStreamwritable-is-dead-code" Pull request url: https://github.com/pharo-project/pharo/pull/1827 Issue Url: https://pharo.fogbugz.com/f/cases/22490 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Sept. 27, 2018

Re: [Pharo-dev] [Pharo-users] [ANN] Success story Mobility Map

by Norbert Hartl

> Am 25.09.2018 um 17:44 schrieb Sven Van Caekenberghe <sven(a)stfx.eu>: > > > >> On 25 Sep 2018, at 14:39, Norbert Hartl <norbert(a)hartl.name> wrote: >> >> >> >>> Am 25.09.2018 um 12:52 schrieb Sven Van Caekenberghe <sven(a)stfx.eu>: >>> >>> Wow. Very nice, well done. >>> >>> Any chance on some more technical details, as in what 'connected by a message queue for the communication' exactly means ? How did you approach micro services exactly ? >>> >> Sure :) > > Thanks, this is very interesting ! > >> The installation spawns multiple physical machines. All the machines are joined to a docker swarm. The installation is reified as either task or service from the view on the docker swarm. Meaning you instantiate an arbitrary amount of services and docker swarm distributes them among the physical machines. Usually you donât take control which is running where but you can. At this point you have spread dozens of pharo images among multiple machines and each of them has an IP address. Furthermore in docker swarm you have a reification of a network meaning that every instance in a network can see all other instances on this network. Each service can be reached by its service name in that network. Docker swarm does all the iptables/firewall and DNS setup for you. > > Are you happy with docker swarm's availability/fail-over behaviour ? In other words: does it work when one image/instance goes bad, does it detect and restore the missing functionality ? > Yes, Iâm very satisified. Instances are automatically restarted if they crash. And not necessarily on the same machine exactly how I expect it. Docker has something called Healthcheck. You can have a command executed every 20 seconds. I hooked this to a curl command and to your SUnit Rest handler. The rest is writing unit tests for server health. If tests fail in sequence the instances are taken out of operation and are replaced with a new instance. The same is done for updating. Instances are started in a fashion that one instance of the new image is started, if it survives a couple of health checks it is taken operational and an old one is taken out. Then the next new is started... For simple software updates you have zero-downtime deployment. >> In order to have communication between those runtimes we use rabbitmq because you were so nice writing a driver for it ;) The rabbitmq does have a support for cluster setup, meaning each of the physical machines has a rabbitmq installation and they know each other. So it does not matter to which instance you send messages to and on which you register for receiving messages. So every pharo image connects to the service rabbitmq and opens a queue for interaction. > > Same question: does RabbitMQ's clustering work well under stress/problems ? Syncing all queues between all machines sounds quite heavy (I never tried it, but maybe it just works). I did not yet have time to real stress test the queue. And you are right copying between nodes might be a lot but still I have the feeling it is better to have then a single instance but no real reason. We also use huge payloads which might have to change if we encounter problems. > >> Each service like the car sharing opens a queue e.g. /queue/carSharing and listens on it. The broker images are stateful so they open queues like /queue/mobility-map-afdeg32 where afdeg32 is the container id of the instance (hostname in docker). In each request the queue name to reply is sent as a header. So we can make sure that the right image gets the message back. This way we can have sticky sessions keeping volatile data in memory for the lifecycle of a session. There is one worker image which opens a queue /queue/mobility-map where session independent requests can be processed. > > I think I understand ;-) > >> In order to ease development we are sharing code between the broker and the micro service. Each micro service has a -Common package where the classes are in that build the interface. The classes in here are a kind of data entity facades. They use NeoJSON to map to and from a stream. The class name is send with the message as a header so the remote side knows what to materialize. The handling is unified for the four cases >> >> - Request as inquiry to another micro service >> - Response returns values to a Request >> - Error is transferred like a Response but is then signalled on the receiving side >> - Notification connects the announcers on the broker and the micro service side. > > Yes, makes total sense. > >> Asynchronous calls we solved using Promises and Futures. Each async call to the Q becomes a promise (that blocks on #value) and is combined to a future value containing all promises with support to generate a delta of all resolved promises. This we need because you issue a search that takes longer and you want to display results as soon as they are resolved not after all haven been resolved. > > Which Promise/Future framework/library are you using in Pharo ? > We rolled our own. And I donât know about other frameworks. > You did not go for single threaded worker images ? For the micro services yes. They read from the queue one by one and process it. Here I scale out with multiple pharo instances. On the API image we have zinc for HTTP that is a multithreaded server and the clients are polling. Norbert > >> And a lot more. This is a coarse grained overview over the architecture. Iâm happy to answer further questions about this. >> >> Norbert >> >>>> On 25 Sep 2018, at 12:20, Norbert Hartl <norbert(a)hartl.name> wrote: >>>> >>>> As presented on ESUG here is the brief description of one of our current projects. >>>> >>>> Mobility Map >>>> ââââââ >>>> >>>> Mobility Map is a broker for mobility services. It offers multi-modal routing search enabling users to find the best travel options between locations. Travel options include car sharing, bikes, trains, busses etc. Rented cars can be offered for ride sharing on booking time letting other people find it to participate in the ride. Single travel options are combined in travel plans that can be booked and managed in a very easy way. >>>> >>>> For this project main requirements were scalability to serve a large user base and flexibility to add more additional providers to the broker. The application has been realized using web technologies for the frontend and pharo for the backend. Using a microservice architecture combined with a broker it is easy to extend the platform with additional brokers. Deployment is done using docker swarm for distributing dozens of pharo images among multiple server machines connected by a message queue for the communication. Pharo supported that scenario very well enabling us the meet the requirements with less effort. >>>> >>>> Pharo turned out to be a perfect fit to develop the application in a agile way. Small development cycles with continuous integration and continuous delivery enables fast turnarounds for the customers to validate progress. >>>> >>>> This is a screenshot of the search page for multi-modal results: >>>> >>>> >>>> <Screen Shot 2018-09-21 at 16.54.30.png> >>> >>> >> >> > >

Sept. 26, 2018

Re: [Pharo-dev] [Pharo-users] [ANN] Success story Mobility Map

by Nicolas Cellier

Very nice proof that we can leverage efficient and up to date technologies ! Thank you so much for sharing, that's the right way to make Pharo (and Smalltalk) alive and kicking. How did the Pharo IDE help in such context? (did you use debugging facility extensively?). What tool is missing? Le mar. 25 sept. 2018 Ã 17:45, Sven Van Caekenberghe <sven(a)stfx.eu> a Ã©crit : > > > > On 25 Sep 2018, at 14:39, Norbert Hartl <norbert(a)hartl.name> wrote: > > > > > > > >> Am 25.09.2018 um 12:52 schrieb Sven Van Caekenberghe <sven(a)stfx.eu>: > >> > >> Wow. Very nice, well done. > >> > >> Any chance on some more technical details, as in what 'connected by a > message queue for the communication' exactly means ? How did you approach > micro services exactly ? > >> > > Sure :) > > Thanks, this is very interesting ! > > > The installation spawns multiple physical machines. All the machines are > joined to a docker swarm. The installation is reified as either task or > service from the view on the docker swarm. Meaning you instantiate an > arbitrary amount of services and docker swarm distributes them among the > physical machines. Usually you donât take control which is running where > but you can. At this point you have spread dozens of pharo images among > multiple machines and each of them has an IP address. Furthermore in docker > swarm you have a reification of a network meaning that every instance in a > network can see all other instances on this network. Each service can be > reached by its service name in that network. Docker swarm does all the > iptables/firewall and DNS setup for you. > > Are you happy with docker swarm's availability/fail-over behaviour ? In > other words: does it work when one image/instance goes bad, does it detect > and restore the missing functionality ? > > > In order to have communication between those runtimes we use rabbitmq > because you were so nice writing a driver for it ;) The rabbitmq does have > a support for cluster setup, meaning each of the physical machines has a > rabbitmq installation and they know each other. So it does not matter to > which instance you send messages to and on which you register for receiving > messages. So every pharo image connects to the service rabbitmq and opens a > queue for interaction. > > Same question: does RabbitMQ's clustering work well under stress/problems > ? Syncing all queues between all machines sounds quite heavy (I never tried > it, but maybe it just works). > > > Each service like the car sharing opens a queue e.g. /queue/carSharing > and listens on it. The broker images are stateful so they open queues like > /queue/mobility-map-afdeg32 where afdeg32 is the container id of the > instance (hostname in docker). In each request the queue name to reply is > sent as a header. So we can make sure that the right image gets the message > back. This way we can have sticky sessions keeping volatile data in memory > for the lifecycle of a session. There is one worker image which opens a > queue /queue/mobility-map where session independent requests can be > processed. > > I think I understand ;-) > > > In order to ease development we are sharing code between the broker and > the micro service. Each micro service has a -Common package where the > classes are in that build the interface. The classes in here are a kind of > data entity facades. They use NeoJSON to map to and from a stream. The > class name is send with the message as a header so the remote side knows > what to materialize. The handling is unified for the four cases > > > > - Request as inquiry to another micro service > > - Response returns values to a Request > > - Error is transferred like a Response but is then signalled on the > receiving side > > - Notification connects the announcers on the broker and the micro > service side. > > Yes, makes total sense. > > > Asynchronous calls we solved using Promises and Futures. Each async call > to the Q becomes a promise (that blocks on #value) and is combined to a > future value containing all promises with support to generate a delta of > all resolved promises. This we need because you issue a search that takes > longer and you want to display results as soon as they are resolved not > after all haven been resolved. > > Which Promise/Future framework/library are you using in Pharo ? > > You did not go for single threaded worker images ? > > > And a lot more. This is a coarse grained overview over the architecture. > Iâm happy to answer further questions about this. > > > > Norbert > > > >>> On 25 Sep 2018, at 12:20, Norbert Hartl <norbert(a)hartl.name> wrote: > >>> > >>> As presented on ESUG here is the brief description of one of our > current projects. > >>> > >>> Mobility Map > >>> ââââââ > >>> > >>> Mobility Map is a broker for mobility services. It offers multi-modal > routing search enabling users to find the best travel options between > locations. Travel options include car sharing, bikes, trains, busses etc. > Rented cars can be offered for ride sharing on booking time letting other > people find it to participate in the ride. Single travel options are > combined in travel plans that can be booked and managed in a very easy way. > >>> > >>> For this project main requirements were scalability to serve a large > user base and flexibility to add more additional providers to the broker. > The application has been realized using web technologies for the frontend > and pharo for the backend. Using a microservice architecture combined with > a broker it is easy to extend the platform with additional brokers. > Deployment is done using docker swarm for distributing dozens of pharo > images among multiple server machines connected by a message queue for the > communication. Pharo supported that scenario very well enabling us the meet > the requirements with less effort. > >>> > >>> Pharo turned out to be a perfect fit to develop the application in a > agile way. Small development cycles with continuous integration and > continuous delivery enables fast turnarounds for the customers to validate > progress. > >>> > >>> This is a screenshot of the search page for multi-modal results: > >>> > >>> > >>> <Screen Shot 2018-09-21 at 16.54.30.png> > >> > >> > > > > > > >

Sept. 26, 2018

Re: [Pharo-dev] [Pharo 7.0-dev] Build #1271: 22483-CollectiongroupedBy---preserve-key-order-in-final-grouped-dictionary

by Esteban Lorenzano

> On 26 Sep 2018, at 15:24, Petr Fischer via Pharo-dev <pharo-dev(a)lists.pharo.org> wrote: > > > From: Petr Fischer <petr.fischer(a)me.com> > Subject: Re: [Pharo-dev] [Pharo 7.0-dev] Build #1271: 22483-CollectiongroupedBy---preserve-key-order-in-final-grouped-dictionary > Date: 26 September 2018 at 15:24:49 CEST > To: Pharo Development List <pharo-dev(a)lists.pharo.org> > > > Hello, why is test status of this pull request: FAILURE? > > Thanks for clarification, Petr Fischer Is a misleading message. It means merge was done, but for some reason (usually network problems), some tests failed to run. We are working on fix that (but you knowâ¦ time :P). Esteban > > >> There is a new Pharo build available! >> >> The status of the build #1271 was: FAILURE. >> >> The Pull Request #1823 was integrated: "22483-CollectiongroupedBy---preserve-key-order-in-final-grouped-dictionary" >> Pull request url: https://github.com/pharo-project/pharo/pull/1823 >> >> Issue Url: https://pharo.fogbugz.com/f/cases/22483 >> Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2… > > > >

Sept. 26, 2018

Re: [Pharo-dev] [Pharo 7.0-dev] Build #1271: 22483-CollectiongroupedBy---preserve-key-order-in-final-grouped-dictionary

by Marcus Denker

Hi, It means that the build for this one merge failedâ¦ build got much more stable over the last weeks, but we still sometimes have crashes (here it seems to be the text render bug) But this is undefended of the merge: the next build then will take this into account. > On 26 Sep 2018, at 15:24, Petr Fischer via Pharo-dev <pharo-dev(a)lists.pharo.org> wrote: > > > From: Petr Fischer <petr.fischer(a)me.com> > Subject: Re: [Pharo-dev] [Pharo 7.0-dev] Build #1271: 22483-CollectiongroupedBy---preserve-key-order-in-final-grouped-dictionary > Date: 26 September 2018 at 15:24:49 CEST > To: Pharo Development List <pharo-dev(a)lists.pharo.org> > > > Hello, why is test status of this pull request: FAILURE? > > Thanks for clarification, Petr Fischer > > >> There is a new Pharo build available! >> >> The status of the build #1271 was: FAILURE. >> >> The Pull Request #1823 was integrated: "22483-CollectiongroupedBy---preserve-key-order-in-final-grouped-dictionary" >> Pull request url: https://github.com/pharo-project/pharo/pull/1823 >> >> Issue Url: https://pharo.fogbugz.com/f/cases/22483 >> Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2… > > > >

Sept. 26, 2018

Re: [Pharo-dev] [Pharo 7.0-dev] Build #1271: 22483-CollectiongroupedBy---preserve-key-order-in-final-grouped-dictionary

by Petr Fischer

Hello, why is test status of this pull request: FAILURE? Thanks for clarification, Petr Fischer > There is a new Pharo build available! > > The status of the build #1271 was: FAILURE. > > The Pull Request #1823 was integrated: "22483-CollectiongroupedBy---preserve-key-order-in-final-grouped-dictionary" > Pull request url: https://github.com/pharo-project/pharo/pull/1823 > > Issue Url: https://pharo.fogbugz.com/f/cases/22483 > Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Sept. 26, 2018

[Pharo 7.0-dev] Build #1271: 22483-CollectiongroupedBy---preserve-key-order-in-final-grouped-dictionary

by ci-pharo-ci-jenkins2＠inria.fr

There is a new Pharo build available! The status of the build #1271 was: FAILURE. The Pull Request #1823 was integrated: "22483-CollectiongroupedBy---preserve-key-order-in-final-grouped-dictionary" Pull request url: https://github.com/pharo-project/pharo/pull/1823 Issue Url: https://pharo.fogbugz.com/f/cases/22483 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Sept. 26, 2018

[Pharo 7.0-dev] Build #1270: 22221-Jump-to-next-keyword

by ci-pharo-ci-jenkins2＠inria.fr

There is a new Pharo build available! The status of the build #1270 was: SUCCESS. The Pull Request #1722 was integrated: "22221-Jump-to-next-keyword" Pull request url: https://github.com/pharo-project/pharo/pull/1722 Issue Url: https://pharo.fogbugz.com/f/cases/jump Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Sept. 26, 2018

[Pharo 7.0-dev] Build #1269: 22481-NetNameResolver-classlocalHostAddress---error-check-with-default

by ci-pharo-ci-jenkins2＠inria.fr

There is a new Pharo build available! The status of the build #1269 was: FAILURE. The Pull Request #1822 was integrated: "22481-NetNameResolver-classlocalHostAddress---error-check-with-default" Pull request url: https://github.com/pharo-project/pharo/pull/1822 Issue Url: https://pharo.fogbugz.com/f/cases/22481 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Sept. 26, 2018

IoT hackathon @zweidenker

by Norbert Hartl

Hi, we (ZWEIDENKER) and RModD organized an IoT Hackathon in cologne at 19th of october 2018. The plan will be: - Allex Oliviera will present the tutorial he made on PharoThings [1]. The audience will try it in a hands-on-session and give feedback to improve it. Zweidenker is sponsoring the hardware so nobody has to bring anything to the session - We are collecting ideas at the moment what we want to do with the learnings from Allex, meaning what hardware to build - If you have ideas about what to build with real life things that should be connected from pharo, please tell us. We will compile a list of ideas and for the first two or three we will buy the necessary hardware so we can build it at that day The Hackathon will take place at ZWEIDENKER GmbH Luxemburger Str. 72 50674 KÃ¶ln germany As we have a limited amount of seats you need to register if you are interested. Go to http://zweidenker.de/en/iot-hackathon-2018 <http://zweidenker.de/en/iot-hackathon-2018> to register your seat on the session. If there are more participants than seats we will have to do selection by dice rolling. Registration period ends on 5th of october so you will know in advance if you can come. See you there, Norbert on behalf of ZWEIDENKER [1] https://github.com/pharo-iot/PharoThings <https://github.com/pharo-iot/PharoThings>

Sept. 26, 2018