November 2016 - Pharo-users

Re: [Pharo-users] [ANN] CPPBridge: One Ring to rule them ALL

by Dimitris Chloupis

> > Well, a while before that, i wrote own lobotomized smalltalk > implementation in C and started generating bindings to Ogre3D engine. I > even had certain success with it, but then i started grand-rewriting of VM > and abandoned it. > That was before i switched to Squeak, then Pharo. So, your incentives > quite familiar to me :) > I was quite fun journey, and i learned a lot while doing it.. especially > about smalltalk. > > I have no interest into implementing Smalltalk at C side , neither my purpose is education, quite the contrary I try to find way to utilize Pharo the best way possible without compromising on performance > I don't understand why people find assembly scary or mind-boggling? I > dived into assembly few months after i learned my first programming > language, it was Zilog 8-bit CPU. A marvelous gem :) > And this was always fascinating to feel that you can control the > computer's behaviour down to a tiniest detail. We were even researching > what certain i/o ports and interrupts were responsible for by setting > different bits/bytes here and there and see what happen. > Because if you don't understand something down to the tiniest detail - you > cannot be sure that what you doing will work, or work optimally. > So i find it frustrating that most of programmers don't know and not even > thinking about touching assembly. Because it very simple, straightforward > and megalomaniac-rewarding :) > -- > Best regards, > Igor Stasenko. > Assembly is hard, just compare its hello world with the hello world of other progamming languages. Its just insane. The thing is that because we started on early , we experienced assembly when it used to be fairly simple. I started with an Amstrad CPC 6128 with 128 kb of ram and 4 mhz CPU, it uses Z80 assembly which is fairly simple even when compared to Pharo. Modern Assembly however have grown on complexity because it depend on the complexity of the hardware. Personally I don even like to call it a programming language , just beautified machine code. I agree though Assembly is a lot of fun and a great source of knowledge.

Nov. 10, 2016

Re: [Pharo-users] about balkanisation

by phil＠highoctane.be

On Thu, Nov 10, 2016 at 10:12 AM, Thierry Goubier <thierry.goubier(a)gmail.com > wrote: > Hi Dale, > > 2016-11-10 6:04 GMT+01:00 Dale Henrichs <dale.henrichs(a)gemtalksystems.com> > : > >> >> >> On 11/8/16 7:09 AM, Thierry Goubier wrote: >> >> Hi Dale, >> >> 2016-11-08 2:03 GMT+01:00 Dale Henrichs <dale.henrichs(a)gemtalksystems.com >> >: >> >>> [ snip ... ] >>> >>> yes I think this is the area where a Metallo Project Browser comes into >>> play. The technology for committing the dirty packages in a a >>> ConfigurationOf has been around for quite awhile, but a tool that unifies >>> the "multi-package" commit for ConfigurationOf and BaselineOf hasn't popped >>> out of the wood work ... >>> >> >> I'm having some issues with the scripting approach of Metacello, for >> that. Just manipulating a baseline in the Metacello registry (locking it) >> seems to be like writing a compiler code generation item: write a Metacello >> script ;) (Metacello>>#lock contains interesting code). >> >> I think I agree:) ... that is why i am talking about a tool ... >> developers shouldn't have to pass around workspaces to load and manipulate >> projects .. a project tool can partially automate the process, but I >> believe that there needs to be a "load spec" object that can be passed >> around and massaged by code instead of requiring a user to edit a Smalltalk >> workspace ... it's what I do in tODE ... the only times I have to write >> Smalltalk load scripts is when I work in Pharo :) >> > > Agreed. I would just like to find out which object can be used to act upon > (can I call lock on a Metacello project spec... apparently not :))... I'm > not too keen on adding another layer on top of it, first because I'm not > that found of unneeded layers, second because it may mean a significant > rewrite of the environment (have dozens of methods like MyLayer>>#load > which is just a call to Metacello load) to get something that starts > working. > > I'm not in a position to impose large scale changes in the Pharo > ecosystem; it's the consortium role to take and impose such choices. I can > only, like GitFileTree, inject something at a lower level that allow people > to complement and experiment with... > >> >> >> I will repeat that I don't think Pharo should do exactly what I've done >> with tODE, but a Metacello Project Browser and some sort of "load spec" >> object that is shared amongst a cluster of images is something that needs >> to be seriously considered ... >> > > I'm really willing to also make something helping to work with Baselines / > Configurations because I think they present a significant complexity > barrier to the proper use of Metacello features, and I don't see any path > avoiding us to write those, given how complex it may be. > Now a BaselineOf is a ConfigurationOf but such things cannot be put in the Catalog because well, there is some incompatibility happening. Getting BaselineOf usable right away would be a small step but a great step. I find myself having to write a BaselineOf for the Git repo and a ConfigurationOfXXX usign the old scheme to be put in the Catalog and pointing to the BaselineOf. Could someone point to the reason why? > >> >> >>> >>> >>> What is a bit annoying, really, is this talk of rewriting everything >>> where some of the pieces (the project browsing you're talkin about, for >>> example) is already there in the image, just not exposed. >>> >>> Well I am annoyed as well .. I would say that perhaps we are in >>> screaming agreement ... I've said that I don't think it's a lot of work to >>> do the project-centric tool. but a project-centric tool that encompasses >>> both ConfigurationOf and BaselineOf will expose the features that "are >>> already there" >>> >>> >>> I'm trying to code a little something for that... stay tuned for a >>> screenshot soon. >>> >>> Cool:) >>> >> >> And here it is! I'm still fighting with the Metacello lock / unlock thing. >> >> [image: Images intÃ©grÃ©es 1] >> >> If Pharo was more really modular in configurations and baselines, then I >> would see more things into the registry and I could group packages based on >> that (instead of having to prepare a ad-hoc classification for my my >> browser). >> >> Yes this is headed in the right direction ... I am in Argentina this week >> so it isn't easy for me to do much collaboration, but I would love to help >> you with your lock problem next week ... For example ... you do not want to >> directly expose the Metacello registry as there are "hybrid projects" where >> a ConfigurationOf causes a BaselineOf to be loaded, so the BaselineOf needs >> to take precedence (I have code for resolving this) and I strongly suggest >> that the Project Browser not be built-into the Class Browser, but be a >> separate tool like the CataLogBrowser ... but this is just a suggestion --- >> a separate tool dedicated only to loaded Projects and unloaded Projects of >> interest allows one to get a very quick overview of what is in the project >> or not and when version skew pops up, one can easily see the affected >> projects ... embedding this kind of information in the code browser can >> make it hard to get the overview and if you choose to live with version >> skew can be annoying to ignore .... again these are just my thoughts .. >> > > I'm of a different mind on this. Giving access to the Metacello registry > explains well to me what is happening in the system; as long as the GUI > accelerate a significant subset of the common operations, then I'll > consider it good enough and have it working on a short time frame. > Already having the GTPlayground showing an inspector after loading is nice these days. Before it was more convoluted to understand what was going on. The inspector panes kind of rewrite things their way but still nice to have. > Otherwise, you end up with projects like libgit / Iceberg, which are > taking significantly longer to reach a better solution... Exposing the > exponential time needed to reach the perfect solution. > What is Iceberg trying to solve exactly? Ah, and I found why my Pharo5 image explodes when using GitFileTree on Windows: because of ProcessWrapper trying to use git which is in turn not in the path, and then boom. > > I also hate information duplication: why do I have to write a complex > project spec where most (all?) of it has to be rewritten in a different > form in a BaselineOf? Same goes for the forks you described the other day: > why do I have to write in my project description the information I also > have to add inside the repository (an upstream remote) to manage updating > with the master project? > There is too much stuff to understand to get anything used by a layman. There isn't so much to do with tools like npm.js etc: write your json thing for the package, use semver and this is all looking logical. So that one can get a junior dev handle it in a day. Try that with what we have. Phil > > For version skew, I must be a bit like git designers on that. It has to be > an action (a git pull), and this action is required in git anyway (git pull > upstream / git pull origin) .. I have no opinion on whether a GUI has to > automatically check that everytime I open the project browser. > > >> >> Regardless I think you are definitely headed in the right direction and >> it isn't all that much work ... yet:) >> > > I need to keep it reasonable to be able to tackle it :) > > Thierry > > >> >> >> Dale >> > >

Nov. 10, 2016

Re: [Pharo-users] Can pharo association web page point to association.pharo.org, like the consortium one?

by Tudor Girba

Great work, Marcus! This type of work often goes unnoticed and under appreciated. But, it is acts like this that make Pharo more than a language, environment or even code. Pharo is a community. A way of working. Pharo is a project. Cheers, Doru > On Nov 10, 2016, at 9:44 AM, Marcus Denker <marcus.denker(a)inria.fr> wrote: > > >> On 5 Nov 2016, at 12:31, Marcus Denker <marcus.denker(a)inria.fr> wrote: >> >> Hi, >> >> Current Status: >> >> - SPF record DONE, mails are now send from @association.pharo.org >> - DNS setup now uses association.pharo.org for normal viewing, just forms forward to https://pharo.wildapricot.org >> This will change as soon as the SSL certificate setup is completed, which will be next week. >> > > SSL setup is DONE. > > https://association.pharo.org > > > The site is now fully operational. > > Marcus > -- www.tudorgirba.com www.feenk.com âLive like you mean it."

Nov. 10, 2016

Re: [Pharo-users] [ANN] Pharo Association has a new Website!

by Marcus Denker

> On 10 Nov 2016, at 10:22, Marcus Denker <marcus.denker(a)inria.fr> wrote: > > Hello, > > We have changed the backend of the Pharo Association. > > https://association.pharo.org <https://association.pharo.org/> > > If you ever joined the association in the past, please consider to re-subscribe. > > We have added already all existing active members, in this case you should > have already received a new password. > > For all questions, do not hesitate to contact assocation(a)pharo.org <mailto:assocation@pharo.org> ups: Pharo Association <association(a)pharo.org>

Nov. 10, 2016

[ANN] Pharo Association has a new Website!

by Marcus Denker

Hello, We have changed the backend of the Pharo Association. https://association.pharo.org <https://association.pharo.org/> If you ever joined the association in the past, please consider to re-subscribe. We have added already all existing active members, in this case you should have already received a new password. For all questions, do not hesitate to contact assocation(a)pharo.org <mailto:assocations@pharo.org> Marcus

Nov. 10, 2016

Re: [Pharo-users] about balkanisation

by Thierry Goubier

Hi Dale, 2016-11-10 6:04 GMT+01:00 Dale Henrichs <dale.henrichs(a)gemtalksystems.com>: > > > On 11/8/16 7:09 AM, Thierry Goubier wrote: > > Hi Dale, > > 2016-11-08 2:03 GMT+01:00 Dale Henrichs <dale.henrichs(a)gemtalksystems.com> > : > >> [ snip ... ] >> >> yes I think this is the area where a Metallo Project Browser comes into >> play. The technology for committing the dirty packages in a a >> ConfigurationOf has been around for quite awhile, but a tool that unifies >> the "multi-package" commit for ConfigurationOf and BaselineOf hasn't popped >> out of the wood work ... >> > > I'm having some issues with the scripting approach of Metacello, for that. > Just manipulating a baseline in the Metacello registry (locking it) seems > to be like writing a compiler code generation item: write a Metacello > script ;) (Metacello>>#lock contains interesting code). > > I think I agree:) ... that is why i am talking about a tool ... developers > shouldn't have to pass around workspaces to load and manipulate projects .. > a project tool can partially automate the process, but I believe that there > needs to be a "load spec" object that can be passed around and massaged by > code instead of requiring a user to edit a Smalltalk workspace ... it's > what I do in tODE ... the only times I have to write Smalltalk load scripts > is when I work in Pharo :) > Agreed. I would just like to find out which object can be used to act upon (can I call lock on a Metacello project spec... apparently not :))... I'm not too keen on adding another layer on top of it, first because I'm not that found of unneeded layers, second because it may mean a significant rewrite of the environment (have dozens of methods like MyLayer>>#load which is just a call to Metacello load) to get something that starts working. I'm not in a position to impose large scale changes in the Pharo ecosystem; it's the consortium role to take and impose such choices. I can only, like GitFileTree, inject something at a lower level that allow people to complement and experiment with... > > > I will repeat that I don't think Pharo should do exactly what I've done > with tODE, but a Metacello Project Browser and some sort of "load spec" > object that is shared amongst a cluster of images is something that needs > to be seriously considered ... > I'm really willing to also make something helping to work with Baselines / Configurations because I think they present a significant complexity barrier to the proper use of Metacello features, and I don't see any path avoiding us to write those, given how complex it may be. > > >> >> >> What is a bit annoying, really, is this talk of rewriting everything >> where some of the pieces (the project browsing you're talkin about, for >> example) is already there in the image, just not exposed. >> >> Well I am annoyed as well .. I would say that perhaps we are in screaming >> agreement ... I've said that I don't think it's a lot of work to do the >> project-centric tool. but a project-centric tool that encompasses both >> ConfigurationOf and BaselineOf will expose the features that "are already >> there" >> >> >> I'm trying to code a little something for that... stay tuned for a >> screenshot soon. >> >> Cool:) >> > > And here it is! I'm still fighting with the Metacello lock / unlock thing. > > [image: Images intÃ©grÃ©es 1] > > If Pharo was more really modular in configurations and baselines, then I > would see more things into the registry and I could group packages based on > that (instead of having to prepare a ad-hoc classification for my my > browser). > > Yes this is headed in the right direction ... I am in Argentina this week > so it isn't easy for me to do much collaboration, but I would love to help > you with your lock problem next week ... For example ... you do not want to > directly expose the Metacello registry as there are "hybrid projects" where > a ConfigurationOf causes a BaselineOf to be loaded, so the BaselineOf needs > to take precedence (I have code for resolving this) and I strongly suggest > that the Project Browser not be built-into the Class Browser, but be a > separate tool like the CataLogBrowser ... but this is just a suggestion --- > a separate tool dedicated only to loaded Projects and unloaded Projects of > interest allows one to get a very quick overview of what is in the project > or not and when version skew pops up, one can easily see the affected > projects ... embedding this kind of information in the code browser can > make it hard to get the overview and if you choose to live with version > skew can be annoying to ignore .... again these are just my thoughts .. > I'm of a different mind on this. Giving access to the Metacello registry explains well to me what is happening in the system; as long as the GUI accelerate a significant subset of the common operations, then I'll consider it good enough and have it working on a short time frame. Otherwise, you end up with projects like libgit / Iceberg, which are taking significantly longer to reach a better solution... Exposing the exponential time needed to reach the perfect solution. I also hate information duplication: why do I have to write a complex project spec where most (all?) of it has to be rewritten in a different form in a BaselineOf? Same goes for the forks you described the other day: why do I have to write in my project description the information I also have to add inside the repository (an upstream remote) to manage updating with the master project? For version skew, I must be a bit like git designers on that. It has to be an action (a git pull), and this action is required in git anyway (git pull upstream / git pull origin) .. I have no opinion on whether a GUI has to automatically check that everytime I open the project browser. > > Regardless I think you are definitely headed in the right direction and it > isn't all that much work ... yet:) > I need to keep it reasonable to be able to tackle it :) Thierry > > > Dale >

Nov. 10, 2016

Re: [Pharo-users] Can pharo association web page point to association.pharo.org, like the consortium one?

by Marcus Denker

> On 5 Nov 2016, at 12:31, Marcus Denker <marcus.denker(a)inria.fr> wrote: > > Hi, > > Current Status: > > - SPF record DONE, mails are now send from @association.pharo.org > - DNS setup now uses association.pharo.org <http://association.pharo.org/> for normal viewing, just forms forward to https://pharo. <https://pharo.assocation/>wildapricot.org <http://wildapricot.org/> > This will change as soon as the SSL certificate setup is completed, which will be next week. > SSL setup is DONE. https://association.pharo.org <https://association.pharo.org/> The site is now fully operational. Marcus

Nov. 10, 2016

Re: [Pharo-users] about balkanisation

by Igor Stasenko

On 10 November 2016 at 06:07, Dale Henrichs < dale.henrichs(a)gemtalksystems.com> wrote: > > > On 11/8/16 11:04 PM, Igor Stasenko wrote: > > > > On 7 November 2016 at 14:28, stepharo <stepharo(a)free.fr> wrote: > >> >> [ ... ] >> >> >> And this one I don't understand. A smooth, git / iceberg oriented >> transition over Monticello/Metacello is perfectly doable... As Dale >> explained. A nice Iceberg gui reworking / making git usable is perfect. >> >> But why make the transition so hard? You get Stef angry on a Sunday >> morning because he can't find things anymore... even if he is a strong >> proponent of the strategy he complains about ;) >> >> >> No my point was not that. >> My point is that it is important to pay attention and not to add more >> noise than necessary. Let us take the time and move alltogether. >> >> If you want to get somewhere with this story, you don't want to wait till > everything will be ready. > Transition will never start unless you force users to enter the minefield > and let them clear the mines for you. Step by step. Many will blow > themselves up, while some will manage to pass unhurt.. > Because else, it will be always a minefield between you and the > destination of your journey :) > > I think that at the early stages of the transition you have to support > both approaches ... when the new tools are in place and stabilized then one > can consider ... the transition has already started so this is not a case > where you need to force folks to change, but a case where you need to > support the folks who choose to change ... it can be relatively low cost to > keep the old tools around for quite awhile ... I would think ... > > Right, as i said: make a minefield and watch those who wanting to cross it. And big mistake then to shout: hey i will never ever step on it.. This is bad idea, since you discouraging people from doing what you need :) > Dale > -- Best regards, Igor Stasenko.

Nov. 10, 2016

Re: [Pharo-users] MOOC TOC cleanup

by Siemen Baader

On 10/11/2016, at 07.32, "Sven Van Caekenberghe-2 [via Smalltalk]" <ml-node+s1294792n4922444h34(a)n4.nabble.com> wrote: > Wow, this is beautiful, well done ! Thanks, I'm glad you like it. I like your zinc docs ;) Siemen > > > On 10 Nov 2016, at 07:21, Siemen Baader <[hidden email]> wrote: > > > > Hi Stef, > > > > I have cloned the repository and linked the slides directly from the TOC. I also have styled it with Bootstrap labels and glyphicons, and added anchors to every item to make them easily linkable, eg for discussions on the mailing list / slack. > > > > The HTML files for the exercises refer to the directory 'support' ( http://rmod-pharo-mooc.lille.inria.fr/MOOC/support ) for css and js files. I think you have missed to put the directory on the server, the links are broken. Can you upload it? > > > > As for the videos, they require some sort of aggregation of subtitles and video, either in a separate HTML file with <video> tags, or eg. on youtube. At some point during or after the MOOC I remember the videos were in fact on youtube, with subtitles. Now they are back in the custom made player on fun-mooc.fr, which is a bit impractical because the subtitles are on the right side, slightly out of view when attending to the lecture. > > > > Are the videos still on youtube? I could not find them again. > > > > Would you prefer a 'full', downloadable solution with the videos and subtitles all on mooc.pharo.org? It would be relatively easy to script something that generates the html files, but it would take more time than linking to the youtube videos, and I think the playback experience on youtube would actually be better / more cross-platform. > > > > I have a put up a preview on https://siemenbaader.github.io/PharoMooc-website/. > > > > What do you think? > > > > best, > > Siemen > > > > > > On Thu, Nov 3, 2016 at 6:31 PM, stepharo <[hidden email]> wrote: > > > > > > Le 3/11/16 Ã 18:05, Siemen Baader a Ã©crit : > >> Hi Stef, > >> > >> Sure. > >> Let me know how I can help. > >> I will forward your mail to christelle that manages the mooc for us > >> > >> Thanks. I'm looking forward to hear from her. > > She translated the page but she is busy I forwarded the email to you. > >> > >> > >> Siemen > >> did you see the web portal > >> http://rmod-pharo-mooc.lille.inria.fr/MOOC/WebPortal/co/pharo.html (we > >> should add a pointer from http://mooc.pharo.org to it) > >> and also the http://mooc.pharo.org page? because we have the full > >> control on this one. > >> And this is on my todo to make sure that people can get an archive with > >> the complete mooc nicely packaged. > >> Now if you want to help it would be great. > >> > >> Sure, we could either do it at fun-mooc.fr or mooc.pharo.org. The latter is cleaner and open to all. How do you generate it, and where is the source? I'd like to have a look. > > The source is on github. > > https://github.com/SquareBracketAssociates/PharoMooc-website > > > >> What is the role of WebPortal? > > the idea was to propose a package to user and we were paid and forced to use this format. > > I would prefer plain HTML (or even pillar). > >> > >> best, > >> Siemen > >> > >> > >> View this message in context: Re: MOOC TOC cleanup > >> Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com. > > > > > > > > > If you reply to this email, your message will be added to the discussion below: > http://forum.world.st/MOOC-TOC-cleanup-tp4921304p4922444.html > To unsubscribe from MOOC TOC cleanup, click here. > NAML -- View this message in context: http://forum.world.st/MOOC-TOC-cleanup-tp4921304p4922446.html Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.

Nov. 10, 2016

Re: [Pharo-users] MOOC TOC cleanup

by Sven Van Caekenberghe

Wow, this is beautiful, well done ! > On 10 Nov 2016, at 07:21, Siemen Baader <siemenbaader(a)gmail.com> wrote: > > Hi Stef, > > I have cloned the repository and linked the slides directly from the TOC. I also have styled it with Bootstrap labels and glyphicons, and added anchors to every item to make them easily linkable, eg for discussions on the mailing list / slack. > > The HTML files for the exercises refer to the directory 'support' ( http://rmod-pharo-mooc.lille.inria.fr/MOOC/support ) for css and js files. I think you have missed to put the directory on the server, the links are broken. Can you upload it? > > As for the videos, they require some sort of aggregation of subtitles and video, either in a separate HTML file with <video> tags, or eg. on youtube. At some point during or after the MOOC I remember the videos were in fact on youtube, with subtitles. Now they are back in the custom made player on fun-mooc.fr, which is a bit impractical because the subtitles are on the right side, slightly out of view when attending to the lecture. > > Are the videos still on youtube? I could not find them again. > > Would you prefer a 'full', downloadable solution with the videos and subtitles all on mooc.pharo.org? It would be relatively easy to script something that generates the html files, but it would take more time than linking to the youtube videos, and I think the playback experience on youtube would actually be better / more cross-platform. > > I have a put up a preview on https://siemenbaader.github.io/PharoMooc-website/. > > What do you think? > > best, > Siemen > > > On Thu, Nov 3, 2016 at 6:31 PM, stepharo <stepharo(a)free.fr> wrote: > > > Le 3/11/16 Ã 18:05, Siemen Baader a Ã©crit : >> Hi Stef, >> >> Sure. >> Let me know how I can help. >> I will forward your mail to christelle that manages the mooc for us >> >> Thanks. I'm looking forward to hear from her. > She translated the page but she is busy I forwarded the email to you. >> >> >> Siemen >> did you see the web portal >> http://rmod-pharo-mooc.lille.inria.fr/MOOC/WebPortal/co/pharo.html (we >> should add a pointer from http://mooc.pharo.org to it) >> and also the http://mooc.pharo.org page? because we have the full >> control on this one. >> And this is on my todo to make sure that people can get an archive with >> the complete mooc nicely packaged. >> Now if you want to help it would be great. >> >> Sure, we could either do it at fun-mooc.fr or mooc.pharo.org. The latter is cleaner and open to all. How do you generate it, and where is the source? I'd like to have a look. > The source is on github. > https://github.com/SquareBracketAssociates/PharoMooc-website > >> What is the role of WebPortal? > the idea was to propose a package to user and we were paid and forced to use this format. > I would prefer plain HTML (or even pillar). >> >> best, >> Siemen >> >> >> View this message in context: Re: MOOC TOC cleanup >> Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com. > >

Nov. 10, 2016