August 2017 - Pharo-dev - lists.pharo.org

Re: [Pharo-dev] [Pharo-users] including Pillar in Pharo image by default

by Dimitris Chloupis

Is it really necessary ? I am more a modular guy , I would love to get an image that 0.1% the size of the current one and offer me a convenient package manager to install the tools I like. I have used Pillar ALOT probably more than any other Pharo library because I was doing Pharo documentation stuff. I have even used Pillar to build my website , yeah I know that is not the pupose of Pillar but with some modification and the addition of a tool I created (Octopus) it help me generate some portion of the website via mustache. Do I want Pillar in ? Nope Already the System Browser looks like a monster ready to eat you alive, I think we need to make the image a lot less threatening especially for newcomers. There is such thing as too much info. Pillar is in the Package Browser you just click and install it if you dont mind the wait because its a rather big install. On Thu, Aug 17, 2017 at 11:27 AM Peter Uhnak <i.uhnak(a)gmail.com> wrote: > Even though I've initiated this discussion I kind of stopped reading > because everyone started discussing completely unrelated things... > > The initial point was.... "we are using github/gitlab more and more, lets > leverage it more" > > New, lets separate the concepts at play here... > > "Pillar - document model" - the workhorse of pillar and (imho) the most > important part of it, and also the part I am interested in being included. > Because then I can generate the document directly without using any > syntax... > > "Pillar - syntax" - we can have endless arguments whether the syntax is > good or bad, and imho that should be a separate discussion unrelated to the > Pillar inclusion > > "Markdown for unrelated usecases" - whether you can or cannot write your > thesis in markdown is really irelevant here > > "Markdown - export" - there will always be different variants and > extensions for Markdown, simply because the sites using markdown offer > different capabilities. > > Therefore the first focus should be on the most impact/effort ratio, which > is CommonMark (basically the only meaningful Markdown specification), and > GFM (which is a CommonMark with added tables and strikethrough). > > Adding support for more extensive export support, whether code related > (e.g. GitLab), or code unrelated (writing a thesis) should be a future > discussion, it is not relevant or too effortful right now. > > "Markdown - import" - I would love to be able to write markdown and have > it imported into the Pillar document model, however that is imho moot point > right now, as it can always be added later > > > To summarize: > > * primary > * include pillar document model > * include pillar syntax (as an import format) > * add CommonMark+GFM export > * secondary > * discuss Pillar syntax if needed (in a _new_ thread) > * discuss Markdown parser / importing CommonMark into Pillar model > * any other discussion not pertinent here should go elsewhere > > Peter > > > On Wed, Aug 16, 2017 at 06:05:29PM +0200, Esteban Lorenzano wrote: > > Hi, > > > > In general (you all know me), I have the policy of âdo not go alien just > becauseâ which means we do not need to reinvent the wheel all the time and > we need to stick with what is already there and known (I have pushed many > changes in pharo following this direction, iceberg being just the latest), > but we need to keep also the basis of what we are (which means: when we > need to stay alien, we need to embrace it too). > > > > Said that: while I would LOVE to have a markdown compatible format, the > amount of effort put on pillar to make it *what we need* and is a format > used not just for doing README.md but to write books, etc., then replacing > it would be complicated. > > > > butâ¦ I think we can do pillar syntax more âmarkdown alikeâ (and we can > even have a stripped-pillar with would be even more like md), I would > salute such change. > > > > cheers, > > Esteban > > > > > > > On 15 Aug 2017, at 19:23, Eliot Miranda <eliot.miranda(a)gmail.com> > wrote: > > > > > > > > > > > > On Aug 15, 2017, at 7:25 AM, Ben Coman <btc(a)openinworld.com <mailto: > btc(a)openinworld.com>> wrote: > > > > > >> > > >> > > >> On Tue, Aug 15, 2017 at 12:54 AM, Esteban A. Maringolo < > emaringolo(a)gmail.com <mailto:emaringolo@gmail.com>> wrote: > > >> You hit several birds with one single mail. > > >> > > >> 2017-08-14 13:34 GMT-03:00 Tim Mackinnon <tim(a)testit.works <mailto: > tim(a)testit.works>>: > > >> > Jimmie et al. nicely reasoned arguments - and Doru's point about > controlling > > >> > the syntax is an interesting one that I hadnât thought about. > > >> > > > >> > Personally, I find having too many similar syntaxâs confusing - > contributing > > >> > to things is hard enough - having to remember that its !! Instead > of ## and > > >> > ââ instead of ** is just frustrating for me. > > >> > > >> +1 > > >> > > >> Not only for docs, most platforms like Slack/Discord share the syntax, > > >> so now I'm getting "muscle memory" when typing literals using the > > >> backtick (`) character, quoting with > or pasting snippets using ``` > > >> > > >> +1. So I've posted this before... > > >> > https://www.joelonsoftware.com/2000/06/03/strategy-letter-iii-let-me-go-bac… > < > https://www.joelonsoftware.com/2000/06/03/strategy-letter-iii-let-me-go-bac… > > > > >> describing that "The only strategy in getting people to switch to > your product is to eliminate barriers" > > >> > > >> But more... the best reason for Pillar to support a Markdown-ish > syntax, is that when we scratch-our-own-itch (nominally for Pillar) to > build the best damn markup-editor ever (because we can!) - if this happened > to support Markdown it can draw in Markdown-non-Pharo users (because its > the best editor ever!). Those users later want to make modifications, and > now have a *reason* to learn Pharo... ahHaA! now you see the cunning plan... > > >> > > >> So don't just promote to people "hey come and play with this cool toy > of ours (Pharo)." > > >> Instead give them a toy they *already-want* (Markdown editor) and > then when they want to change the batteries, they *need* to use our special > screwdriver (Pharo). > > > > > > +1! > > > > > >> > > >> cheers -ben > > >> > > >> > > >> > Sure, maybe we were first with Pillar, but for me, lots of > programming is in > > >> > other languages, and I use Smalltalk where I can, and a hybrid of > multiple > > >> > languages and projects is often the reality - so a lowest common > denominator > > >> > of Markdown is just easier. The fact that we are quite close to > what our > > >> > colleagues in other languages use (regardless of what Python has > chosen), is > > >> > quite interesting. > > >> > > >> This helps building "bridges" with other communities. > > >> > > >> > > >> > > >> > > >> > > >> > > >> The language as a means of exchange is always the lowest common > denominator. > > >> As long as it's "efficient enough" then I vote to use what other > > >> communities use. > > >> > > >> > That said, if the community wants to stick to its gunâs thats fine > - I will > > >> > probably still investigate how to use Commonmark for myself, and > will still > > >> > contribute to Pillar docs where I can (and curse history) - but I > think we > > >> > are long better off trying to join emerging standards where we can > > >> > particularly if they arenât our core language thing. And it just > makes it > > >> > less frictionless for ourselves and newcomers. > > >> > > >> The "Not Invented Here" syndrome is strong among Smalltalkers, it's > > >> important to be aware of this bias and think more than once whether > > >> eating our own dogfood adds value to the core of what Pharo brings. > > >> > > >> I think we missed some good years fighting with our own SCM and in the > > >> end git (or any other file based SCM) prevailed, even when it has > > >> limitations. > > >> > > >> Pareto (80-20) for everything non-core business should be a guide. > > >> > > >> > Of course, if we were to move, we would need to translate a lot of > quality > > >> > docs to a new format - but I would be up for contributing to that > if that > > >> > was a deciding factor. > > >> > > >> There are some Markdown exporters AFAIK, or it could be written. > > >> > > >> > > >> Esteban A. Maringolo > > > >

Aug. 17, 2017

Re: [Pharo-dev] @About posting here

by Dimitris Chloupis

Could not agree more with entirety of your post. Especially the part of the massive improvement of Pharo version 1 vs 6 are like and day. Documentation wise even Unreal with its massive community and one of the most profitable game companies pouring massive resources has many doc problems. In perspective and taking the size of the community into account we do great there too. Personally I am running out of complains , my last ones is code completion and bootstrapping. I would like to thank all contributors for the amazing work. Pharo is not perfect but it is improving blazing fast again taking into account the size of the community. So excited for the future :) On Wed, 16 Aug 2017 at 17:27, phil(a)highoctane.be <phil(a)highoctane.be> wrote: > I don't know why you think that anybody would silence you. > > Just the fact that you bother mentioning that is just a huge internal > insecurity showcase to me. > > Come on, if we cared about popular opinions, this would be a javascript or > nodejs list, not a Pharo list. > I do not care a bit about popularity. > I care about my customers being happy and accounts receivable clearing up > on time so that I can provide for people who depend on me. > > As far as I am concerned, you actively contributed to your channel volume > being set to mute on my side. > That's how you come across and get on my nerves. Not because of what you > write. Because of how. > > I do not have a problem with critics against Pharo, I am cursing daily in > front of it. > So far, my level of cursing is lower when working with Pharo than with > other tool chains. > > Pharo is there, I am happy for it to be around. Since the 1.x era, this > thing has massively improved. Pharo 7 will be wonderful. Bootstrapping, how > great. Massively great. Vector graphics, super. VM seeing major > improvements and speedup. Roassal: awesome. GT: nothing can touch it. > Community: packed to the gills with people who actually deliver working and > innovative code. Want to be part of it? Your loss if you choose not to. > Otherwise, welcome. > > Contribute whatever you can. > > Docs are in a bad state? Grab the docker image for book production at > https://github.com/cdlm/docker-texlive > Clone something like > https://github.com/SquareBracketAssociates/Booklet-Glorp, make a book > about some stuff and push. > > It is all tears in the rain anyway. As if I cared. > > Phil > > On Wed, Aug 16, 2017 at 12:52 PM, Frank-B <frank.berger.software(a)web.de> > wrote: > >> Phil, >> >> nice attempt to drill and silence me! My advise: They all failed! >> >> If somebody can't cope with straight critics or unpopular opinions that >> aint >> my fault. >> >> Frank >> who never worried about being labeled and >> from a country where free speech is still welcome >> >> >> >> -- >> View this message in context: >> http://forum.world.st/Anybody-using-Orca-Smalltalk-to-JavaScript-tp4960519p… >> Sent from the Pharo Smalltalk Developers mailing list archive at >> Nabble.com. >> >>

Aug. 17, 2017

Re: [Pharo-dev] FileSystem fix integration

by Guillermo Polito

FileSystem needs love, Thanks! On Wed, Aug 16, 2017 at 9:22 PM, Alistair Grant <akgrant0710(a)gmail.com> wrote: > Hi Stef, > > On Wed, Aug 16, 2017 at 08:43:24PM +0200, Stephane Ducasse wrote: > > May be you already see it but > > - https://pharo.fogbugz.com/f/cases/19609/FileReference- > base-should-be-before-last-separator > > https://github.com/pharo-project/pharo/pull/137 > > has a merge conflict > > I haven't looked at this at all. I'll try and take a look it at soon > (my daughter's birthday party this weekend, so time is limited :-)). > > > > I will integrate now > > > > - https://pharo.fogbugz.com/f/cases/18084/FileReference-EnsureCreateFile > > https://github.com/pharo-project/pharo/pull/133 > > > > and after when esteban is back we will integrate > > > > https://pharo.fogbugz.com/f/cases/20294/Add-FileAttributesPlugin-to-the- > linux-32-bit-VM > > I'm looking forward to this one :-) > > Cheers, > Alistair > > > > On Wed, Aug 16, 2017 at 3:42 PM, Alistair Grant <akgrant0710(a)gmail.com> > wrote: > > > Hi Stef, > > > > > > On Wed, Aug 16, 2017 at 12:16:52PM +0200, Stephane Ducasse wrote: > > >> I'm integrating 20307 and I would like to really thank you for > > >> - the bug entry description > > >> - all the comments > > >> - and tests in the PR. > > >> > > >> Tx!!! > > > > > > Thanks for your kind words. > > > > > > And for integrating the PR :-) > > > > > > > > > I've re-submitted 20165 Support segment path printing. > > > > > > So the open list is: > > > > > > - https://pharo.fogbugz.com/f/cases/20165/Support-segment- > path-printing > > > - https://github.com/pharo-project/pharo/pull/210 > > > Note that this is a different PR from before, see the comments in > > > the issue. > > > - https://pharo.fogbugz.com/f/cases/18084/FileReference- > EnsureCreateFile > > > https://github.com/pharo-project/pharo/pull/133 > > > - https://pharo.fogbugz.com/f/cases/19609/FileReference- > base-should-be-before-last-separator > > > https://github.com/pharo-project/pharo/pull/137 > > > - https://pharo.fogbugz.com/f/cases/20294/Add- > FileAttributesPlugin-to-the-linux-32-bit-VM > > > This is the first step in fixing FileReference>>isSymlink and > > > extending support for all file attributes returned by stat() and > > > lstat(). > > > The parent issue is: > > > https://pharo.fogbugz.com/f/cases/18279/isSymlink-seems- > to-be-broken-on-Linux > > > > > > > > > Still to be closed (won't fix): > > > > > > - https://pharo.fogbugz.com/f/cases/18042 > > > - https://github.com/pharo-project/pharo/pull/75 > > > > > > > > > And waiting on FFI / kernel resolution: > > > > > > - https://pharo.fogbugz.com/f/cases/5723/ > > > - https://github.com/pharo-project/pharo/pull/92 > > > > > > > > > Cheers, > > > Alistair > > > > > > > > > > -- Guille Polito Research Engineer 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

Aug. 17, 2017

Re: [Pharo-dev] Initial Feedback on Pharo 7 contribution process

by Esteban Lorenzano

Hi, > On 17 Aug 2017, at 11:28, Guillermo Polito <guillermopolito(a)gmail.com> wrote: > > > > On Thu, Aug 17, 2017 at 10:44 AM, Torsten Bergmann <astares(a)gmx.de <mailto:astares@gmx.de>> wrote: > Hi, > > even when contributing to Pharo 7.0 is still very very cumbersome I was able > to sort out most of the problems and contribute already a few smaller things. > > Unfortunately there is not much communication on what is currently in the pipe > or planned on easing the process - which can easily lead to the impression > that we do not really move or slow us down. > > Vacations periodâ¦ most of us :) I will be back next week :P > > > I know step by step it goes and at least we have again the build process rolling > https://pharoweekly.wordpress.com/2017/08/16/pharo-70-is-starting-to-roll-f… <https://pharoweekly.wordpress.com/2017/08/16/pharo-70-is-starting-to-roll-f…> > > Nonetheless one of my PRs was already integrated and the integration of my WebBrowser > package is still in the pipe (https://github.com/pharo-project/pharo/pull/193 <https://github.com/pharo-project/pharo/pull/193>) > > Yes, I need to document better all the process with the baselines, I know :) > > > The descriptions from Guille helped me - but there are still things I need > answers to: > > 1. Will or is it still possible to automatically update" an image in Pharo 7 > or in the future? > The World menu entry "System" -> "System update" has been removed? > > Is this temporary of will it return once we know how it could be done again? > > > AFAIU, this never worked "safelyâ. yes, update is broken since *at least* Pharo 1.4. I do not think is in our priorities to make it back since we are now bootstrapping (and is very different build process). thenâ¦ one of the plugins I would like to see is a âreload all packages following baselineâ which will make it work on most cases. Still, it will not work 100% of the time (as Pavel points, there are issues that would simply not work updatingâ¦ but this cases are not common). Esteban > > > 2. In latest Pharo 7.0 image there is a glitch that a method category > has a typo in class "HEBinaryReaderWriter" and is "writting" instead of > "writing". > > Lets assume I want to fix such a simple problem. But Hermes was an external package managed on GitHub. > And it is now part of the image and therefore also in the "pharo" repo on GitHub. So how is it > maintainted/managed with the new process? > > So do I fix this as a regular PR for Pharo 7 https://github.com/pharo-project/pharo <https://github.com/pharo-project/pharo> > or should it be fixed in the original repo https://github.com/tesonep/hermes <https://github.com/tesonep/hermes> > and Hermes is synched from time to time into or from Pharo. > > My answer to this is: until we support multiple code directories per repository in iceberg (I think that's scheduled for next release), we kind of have a fork (as we had before with the image and people committing to the inbox). > > The good way to do the fix on hermes should be, although a bit cumbersome, the following: > - fix it in hermes repo > - then sync hermes with your pharo fork > - pull request for pharo > > I know these are a lots of steps... > > > 3. What still hit me most is that it is hard to identify the images and find out > how "new" they are. > > Example: In Guilles example https://github.com/guillep/PharoIntegrationProcess/wiki/Contribute-a-fix-to… <https://github.com/guillep/PharoIntegrationProcess/wiki/Contribute-a-fix-to…> > it is written that one should use > > wget -O - get.pharo.org/70+vm <http://get.pharo.org/70+vm> | bash > > This gives me an image file called "Pharo.image" and after a few days I do not know how > old it is or what it was built from. > > When I start the image and look into the about box it gives me > > Pharo 7.0 > Latest update: #0 > > telling me nothing and when I run > > SystemVersion current > > it says "Pharo7.0SNAPSHOT of 16 August 2017 update 0" which is also very useless. > > True, but if you inspect `SystemVersion` you'll see that it contains the hash. Thus there are two issues: > - SystemVersion printing should include more info > - we should put build information into the image (so far it is only in the zip archives in files.pharo.org <http://files.pharo.org/>) > > The first issue should be easy to fix and maybe a good target for a guy trying to make his first PR. > The second issue requires understanding a bit more the bootstrap process (I need to write something more detailed about that, I know, but I'm on vacations right now and from saturday I've no internet). > > I can try to solve them today, I'll not be long I think. > > > Both do not tell me anything about the build number!!! I can only guess the git commit from the name > of the sources file: > > Pharo7.0-32bit-c28bff9.sources > > When I check https://github.com/pharo-project/pharo/commits/development <https://github.com/pharo-project/pharo/commits/development> with "c28bff9" then at least > I have an idea how old it is. > > Especially the last topic is a pain point and the most pressuring to be discussed - without a clear image build number > in the version/about box nobody is able to reproduce in which image one run into trouble or he is basing his work on. > > I know during transition time we need more patience and things will get more stable and we make progress over > time. But I whised we would have more communication on the overall topic (current work, plans, ...) on this list here. > > Well, in part what I wanted as a first milestone is to reach the point where the process is smooth enough to let people contribute. And well... at that point people could contribute :) > > This is my TODO list, if somebody wants to help: > > On the CI and integration front: > - automate integration mails > - automate github/jenkins/fogbugz communication > > On the Iceberg front: > - my main wish is to have a smooth experience while submitting a fix to pharo > - subdirectories (to better manage sub projects) > - less of a hard issue: > - there is a nice plugin architecture, I'd like to see more plugins flourish? > - we need people involving themselves on it. I think Esteban alone cannot with all the issues there. > > On the general build process: > - we need to enhance how packages can be loaded in a `minimal image` > - Right now, we don't have baselines for each pharo subproject. For example, the other day I wanted to install spacetally and I did not have a baseline > - Even if we had baselines, there are ugly dependencies: for example, spacetally depends on morphic. > - I started thinking we need the idea of a MultiProject baseline where a baseline describes a top project with subprojects (baselines) in the same repository > > I have no idea who is working on what already regarding making the process more easier. > > Esteban is Iceberg's fairy-knight. > I was working a lot lately with Christophe to have the ci working and make sure we can integrate PRs and we are not stuck. I made tests green to have a better indication of the process. I started documenting all this. > Pavel is helping with the overall process too. > > From that list, Esteban is the only full time guy. I'm now doing stuff over here and there but I'm on vacations and my relationship may depend on not working so much :P > > Now, sending mails like this is good because they raise good issues. Please, people, raise more like this. For the brave, you can keep trying publishing some Pull request, sharing your experience, documenting stuff... > > > > Thanks for any comments or own feedback you can share. > > Thank **you**, > > Guille > > Regards > T. > > > > > > > -- > > Guille Polito > > Research Engineer > 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

Aug. 17, 2017

Re: [Pharo-dev] Initial Feedback on Pharo 7 contribution process

by Pavel Krivanek

2017-08-17 10:44 GMT+02:00 Torsten Bergmann <astares(a)gmx.de>: > Hi, > > even when contributing to Pharo 7.0 is still very very cumbersome I was > able > to sort out most of the problems and contribute already a few smaller > things. > > Unfortunately there is not much communication on what is currently in the > pipe > or planned on easing the process - which can easily lead to the impression > that we do not really move or slow us down. > > I know step by step it goes and at least we have again the build process > rolling > https://pharoweekly.wordpress.com/2017/08/16/pharo-70-is- > starting-to-roll-for-real/ > > Nonetheless one of my PRs was already integrated and the integration of my > WebBrowser > package is still in the pipe (https://github.com/pharo- > project/pharo/pull/193) > > The descriptions from Guille helped me - but there are still things I need > answers to: > > 1. Will or is it still possible to automatically update" an image in > Pharo 7 > or in the future? > The World menu entry "System" -> "System update" has been removed? > > Is this temporary of will it return once we know how it could be done > again? > You can update your image in Iceberg by switching to the updated #development branch and then to reload all packages. In most cases it will probably work fine but it does not know the right packages loading order, does not know changes in the packages structure etc. And some updates cannot be done at all (e.g. https://github.com/pharo-project/pharo/pull/205) So you can expect troubles. With Cargo we can get smoother updating process but trying to maintain it now would be IMHO waste of resources. -- Pavel

Aug. 17, 2017

Re: [Pharo-dev] Initial Feedback on Pharo 7 contribution process

by Guillermo Polito

On Thu, Aug 17, 2017 at 10:44 AM, Torsten Bergmann <astares(a)gmx.de> wrote: > Hi, > > even when contributing to Pharo 7.0 is still very very cumbersome I was > able > to sort out most of the problems and contribute already a few smaller > things. > > Unfortunately there is not much communication on what is currently in the > pipe > or planned on easing the process - which can easily lead to the impression > that we do not really move or slow us down. > Vacations period... > > I know step by step it goes and at least we have again the build process > rolling > https://pharoweekly.wordpress.com/2017/08/16/pharo-70-is- > starting-to-roll-for-real/ > > Nonetheless one of my PRs was already integrated and the integration of my > WebBrowser > package is still in the pipe (https://github.com/pharo- > project/pharo/pull/193) > Yes, I need to document better all the process with the baselines, I know :) > > The descriptions from Guille helped me - but there are still things I need > answers to: > > 1. Will or is it still possible to automatically update" an image in > Pharo 7 > or in the future? > The World menu entry "System" -> "System update" has been removed? > > Is this temporary of will it return once we know how it could be done > again? > > AFAIU, this never worked "safely". > > 2. In latest Pharo 7.0 image there is a glitch that a method category > has a typo in class "HEBinaryReaderWriter" and is "writting" instead of > "writing". > > Lets assume I want to fix such a simple problem. But Hermes was an > external package managed on GitHub. > And it is now part of the image and therefore also in the "pharo" repo > on GitHub. So how is it > maintainted/managed with the new process? > > So do I fix this as a regular PR for Pharo 7 https://github.com/pharo- > project/pharo > or should it be fixed in the original repo https://github.com/tesonep/ > hermes > and Hermes is synched from time to time into or from Pharo. > My answer to this is: until we support multiple code directories per repository in iceberg (I think that's scheduled for next release), we kind of have a fork (as we had before with the image and people committing to the inbox). The good way to do the fix on hermes should be, although a bit cumbersome, the following: - fix it in hermes repo - then sync hermes with your pharo fork - pull request for pharo I know these are a lots of steps... > > 3. What still hit me most is that it is hard to identify the images and > find out > how "new" they are. > > Example: In Guilles example https://github.com/guillep/ > PharoIntegrationProcess/wiki/Contribute-a-fix-to-Pharo > it is written that one should use > > wget -O - get.pharo.org/70+vm | bash > > This gives me an image file called "Pharo.image" and after a few days > I do not know how > old it is or what it was built from. > > When I start the image and look into the about box it gives me > > Pharo 7.0 > Latest update: #0 > > telling me nothing and when I run > > SystemVersion current > > it says "Pharo7.0SNAPSHOT of 16 August 2017 update 0" which is also > very useless. > True, but if you inspect `SystemVersion` you'll see that it contains the hash. Thus there are two issues: - SystemVersion printing should include more info - we should put build information into the image (so far it is only in the zip archives in files.pharo.org) The first issue should be easy to fix and maybe a good target for a guy trying to make his first PR. The second issue requires understanding a bit more the bootstrap process (I need to write something more detailed about that, I know, but I'm on vacations right now and from saturday I've no internet). I can try to solve them today, I'll not be long I think. > > Both do not tell me anything about the build number!!! I can only > guess the git commit from the name > of the sources file: > > Pharo7.0-32bit-c28bff9.sources > > When I check https://github.com/pharo-project/pharo/commits/ > development with "c28bff9" then at least > I have an idea how old it is. > > Especially the last topic is a pain point and the most pressuring to be > discussed - without a clear image build number > in the version/about box nobody is able to reproduce in which image one > run into trouble or he is basing his work on. > > I know during transition time we need more patience and things will get > more stable and we make progress over > time. But I whised we would have more communication on the overall topic > (current work, plans, ...) on this list here. > Well, in part what I wanted as a first milestone is to reach the point where the process is smooth enough to let people contribute. And well... at that point people could contribute :) This is my TODO list, if somebody wants to help: On the CI and integration front: - automate integration mails - automate github/jenkins/fogbugz communication On the Iceberg front: - my main wish is to have a smooth experience while submitting a fix to pharo - subdirectories (to better manage sub projects) - less of a hard issue: - there is a nice plugin architecture, I'd like to see more plugins flourish? - we need people involving themselves on it. I think Esteban alone cannot with all the issues there. On the general build process: - we need to enhance how packages can be loaded in a `minimal image` - Right now, we don't have baselines for each pharo subproject. For example, the other day I wanted to install spacetally and I did not have a baseline - Even if we had baselines, there are ugly dependencies: for example, spacetally depends on morphic. - I started thinking we need the idea of a MultiProject baseline where a baseline describes a top project with subprojects (baselines) in the same repository > I have no idea who is working on what already regarding making the process > more easier. > Esteban is Iceberg's fairy-knight. I was working a lot lately with Christophe to have the ci working and make sure we can integrate PRs and we are not stuck. I made tests green to have a better indication of the process. I started documenting all this. Pavel is helping with the overall process too. >From that list, Esteban is the only full time guy. I'm now doing stuff over here and there but I'm on vacations and my relationship may depend on not working so much :P Now, sending mails like this is good because they raise good issues. Please, people, raise more like this. For the brave, you can keep trying publishing some Pull request, sharing your experience, documenting stuff... > > Thanks for any comments or own feedback you can share. > > Thank **you**, Guille > Regards > T. > > > > -- Guille Polito Research Engineer 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

Aug. 17, 2017

Re: [Pharo-dev] Issue that may break Epicea

by Guillermo Polito

Why would it break epicea? There is no major change in API. Only the method #createDirectory is removed, but the only users are internal to the library. In my latest image there are no Epicea users of it. On Wed, Aug 16, 2017 at 8:59 PM, Stephane Ducasse <stepharo.self(a)gmail.com> wrote: > Hi martin > > > https://pharo.fogbugz.com/f/cases/18084/FileReference-EnsureCreateFile > https://github.com/pharo-project/pharo/pull/133 > > -- Guille Polito Research Engineer 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

Aug. 17, 2017

Initial Feedback on Pharo 7 contribution process

by Torsten Bergmann

Hi, even when contributing to Pharo 7.0 is still very very cumbersome I was able to sort out most of the problems and contribute already a few smaller things. Unfortunately there is not much communication on what is currently in the pipe or planned on easing the process - which can easily lead to the impression that we do not really move or slow us down. I know step by step it goes and at least we have again the build process rolling https://pharoweekly.wordpress.com/2017/08/16/pharo-70-is-starting-to-roll-f… Nonetheless one of my PRs was already integrated and the integration of my WebBrowser package is still in the pipe (https://github.com/pharo-project/pharo/pull/193) The descriptions from Guille helped me - but there are still things I need answers to: 1. Will or is it still possible to automatically update" an image in Pharo 7 or in the future? The World menu entry "System" -> "System update" has been removed? Is this temporary of will it return once we know how it could be done again? 2. In latest Pharo 7.0 image there is a glitch that a method category has a typo in class "HEBinaryReaderWriter" and is "writting" instead of "writing". Lets assume I want to fix such a simple problem. But Hermes was an external package managed on GitHub. And it is now part of the image and therefore also in the "pharo" repo on GitHub. So how is it maintainted/managed with the new process? So do I fix this as a regular PR for Pharo 7 https://github.com/pharo-project/pharo or should it be fixed in the original repo https://github.com/tesonep/hermes and Hermes is synched from time to time into or from Pharo. 3. What still hit me most is that it is hard to identify the images and find out how "new" they are. Example: In Guilles example https://github.com/guillep/PharoIntegrationProcess/wiki/Contribute-a-fix-to… it is written that one should use wget -O - get.pharo.org/70+vm | bash This gives me an image file called "Pharo.image" and after a few days I do not know how old it is or what it was built from. When I start the image and look into the about box it gives me Pharo 7.0 Latest update: #0 telling me nothing and when I run SystemVersion current it says "Pharo7.0SNAPSHOT of 16 August 2017 update 0" which is also very useless. Both do not tell me anything about the build number!!! I can only guess the git commit from the name of the sources file: Pharo7.0-32bit-c28bff9.sources When I check https://github.com/pharo-project/pharo/commits/development with "c28bff9" then at least I have an idea how old it is. Especially the last topic is a pain point and the most pressuring to be discussed - without a clear image build number in the version/about box nobody is able to reproduce in which image one run into trouble or he is basing his work on. I know during transition time we need more patience and things will get more stable and we make progress over time. But I whised we would have more communication on the overall topic (current work, plans, ...) on this list here. I have no idea who is working on what already regarding making the process more easier. Thanks for any comments or own feedback you can share. Regards T.

Aug. 17, 2017

Re: [Pharo-dev] [Pharo-users] including Pillar in Pharo image by default

by Peter Uhnak

Even though I've initiated this discussion I kind of stopped reading because everyone started discussing completely unrelated things... The initial point was.... "we are using github/gitlab more and more, lets leverage it more" New, lets separate the concepts at play here... "Pillar - document model" - the workhorse of pillar and (imho) the most important part of it, and also the part I am interested in being included. Because then I can generate the document directly without using any syntax... "Pillar - syntax" - we can have endless arguments whether the syntax is good or bad, and imho that should be a separate discussion unrelated to the Pillar inclusion "Markdown for unrelated usecases" - whether you can or cannot write your thesis in markdown is really irelevant here "Markdown - export" - there will always be different variants and extensions for Markdown, simply because the sites using markdown offer different capabilities. Therefore the first focus should be on the most impact/effort ratio, which is CommonMark (basically the only meaningful Markdown specification), and GFM (which is a CommonMark with added tables and strikethrough). Adding support for more extensive export support, whether code related (e.g. GitLab), or code unrelated (writing a thesis) should be a future discussion, it is not relevant or too effortful right now. "Markdown - import" - I would love to be able to write markdown and have it imported into the Pillar document model, however that is imho moot point right now, as it can always be added later To summarize: * primary * include pillar document model * include pillar syntax (as an import format) * add CommonMark+GFM export * secondary * discuss Pillar syntax if needed (in a _new_ thread) * discuss Markdown parser / importing CommonMark into Pillar model * any other discussion not pertinent here should go elsewhere Peter On Wed, Aug 16, 2017 at 06:05:29PM +0200, Esteban Lorenzano wrote: > Hi, > > In general (you all know me), I have the policy of âdo not go alien just becauseâ which means we do not need to reinvent the wheel all the time and we need to stick with what is already there and known (I have pushed many changes in pharo following this direction, iceberg being just the latest), but we need to keep also the basis of what we are (which means: when we need to stay alien, we need to embrace it too). > > Said that: while I would LOVE to have a markdown compatible format, the amount of effort put on pillar to make it *what we need* and is a format used not just for doing README.md but to write books, etc., then replacing it would be complicated. > > butâ¦ I think we can do pillar syntax more âmarkdown alikeâ (and we can even have a stripped-pillar with would be even more like md), I would salute such change. > > cheers, > Esteban > > > > On 15 Aug 2017, at 19:23, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: > > > > > > > > On Aug 15, 2017, at 7:25 AM, Ben Coman <btc(a)openinworld.com <mailto:btc@openinworld.com>> wrote: > > > >> > >> > >> On Tue, Aug 15, 2017 at 12:54 AM, Esteban A. Maringolo <emaringolo(a)gmail.com <mailto:emaringolo@gmail.com>> wrote: > >> You hit several birds with one single mail. > >> > >> 2017-08-14 13:34 GMT-03:00 Tim Mackinnon <tim(a)testit.works <mailto:tim@testit.works>>: > >> > Jimmie et al. nicely reasoned arguments - and Doru's point about controlling > >> > the syntax is an interesting one that I hadnât thought about. > >> > > >> > Personally, I find having too many similar syntaxâs confusing - contributing > >> > to things is hard enough - having to remember that its !! Instead of ## and > >> > ââ instead of ** is just frustrating for me. > >> > >> +1 > >> > >> Not only for docs, most platforms like Slack/Discord share the syntax, > >> so now I'm getting "muscle memory" when typing literals using the > >> backtick (`) character, quoting with > or pasting snippets using ``` > >> > >> +1. So I've posted this before... > >> https://www.joelonsoftware.com/2000/06/03/strategy-letter-iii-let-me-go-bac… <https://www.joelonsoftware.com/2000/06/03/strategy-letter-iii-let-me-go-bac…> > >> describing that "The only strategy in getting people to switch to your product is to eliminate barriers" > >> > >> But more... the best reason for Pillar to support a Markdown-ish syntax, is that when we scratch-our-own-itch (nominally for Pillar) to build the best damn markup-editor ever (because we can!) - if this happened to support Markdown it can draw in Markdown-non-Pharo users (because its the best editor ever!). Those users later want to make modifications, and now have a *reason* to learn Pharo... ahHaA! now you see the cunning plan... > >> > >> So don't just promote to people "hey come and play with this cool toy of ours (Pharo)." > >> Instead give them a toy they *already-want* (Markdown editor) and then when they want to change the batteries, they *need* to use our special screwdriver (Pharo). > > > > +1! > > > >> > >> cheers -ben > >> > >> > >> > Sure, maybe we were first with Pillar, but for me, lots of programming is in > >> > other languages, and I use Smalltalk where I can, and a hybrid of multiple > >> > languages and projects is often the reality - so a lowest common denominator > >> > of Markdown is just easier. The fact that we are quite close to what our > >> > colleagues in other languages use (regardless of what Python has chosen), is > >> > quite interesting. > >> > >> This helps building "bridges" with other communities. > >> > >> > >> > >> > >> > >> > >> The language as a means of exchange is always the lowest common denominator. > >> As long as it's "efficient enough" then I vote to use what other > >> communities use. > >> > >> > That said, if the community wants to stick to its gunâs thats fine - I will > >> > probably still investigate how to use Commonmark for myself, and will still > >> > contribute to Pillar docs where I can (and curse history) - but I think we > >> > are long better off trying to join emerging standards where we can > >> > particularly if they arenât our core language thing. And it just makes it > >> > less frictionless for ourselves and newcomers. > >> > >> The "Not Invented Here" syndrome is strong among Smalltalkers, it's > >> important to be aware of this bias and think more than once whether > >> eating our own dogfood adds value to the core of what Pharo brings. > >> > >> I think we missed some good years fighting with our own SCM and in the > >> end git (or any other file based SCM) prevailed, even when it has > >> limitations. > >> > >> Pareto (80-20) for everything non-core business should be a guide. > >> > >> > Of course, if we were to move, we would need to translate a lot of quality > >> > docs to a new format - but I would be up for contributing to that if that > >> > was a deciding factor. > >> > >> There are some Markdown exporters AFAIK, or it could be written. > >> > >> > >> Esteban A. Maringolo >

Aug. 17, 2017

Re: [Pharo-dev] [Vm-dev] eventual crashes pharo vm

by henry

To let you know what I tried, trying to learn about this system as I dig into it, I added isInteger to the #blockedSelectors of NearERef. This crashed the squeak vm when I ran the test, and as I look into how blockedSelectors is used it smashes the resolver. What seems to be needed is a list of immediateSelectors, though that may grow to be a sizeable list. This causes me to think there must be a different approach between async and sync code. - HH > -------- Original Message -------- > Subject: Re: [Vm-dev] [Pharo-dev] eventual crashes pharo vm > Local Time: August 16, 2017 11:46 PM > UTC Time: August 17, 2017 3:46 AM > From: henry(a)callistohouse.club > To: Eliot Miranda <eliot.miranda(a)gmail.com> > Squeak Virtual Machine Development Discussion <vm-dev(a)lists.squeakfoundation.org>, Pharo Development List <pharo-dev(a)lists.pharo.org>, Marcus Denker <marcus.denker(a)inria.fr> > > Hi Eliot, > > I have disabled that test for the time being. It will require some deeper thought regarding immediate selectors, I think, and I am deep into another area right now. As mustBeBoolean is from inside the VM, a different approach may be the right solution. A part of me thinks autocoercion between msg sending (async) and msg calling (sync) is what is needed, but I want continuation-based VatSemaphores to prevent a liveness lock on the event loop to support. Again, I have not thought deep enough in this area. > > Thanks again for your help, > > - HH > >> -------- Original Message -------- >> Subject: Re: [Pharo-dev] eventual crashes pharo vm >> Local Time: August 16, 2017 10:32 PM >> UTC Time: August 17, 2017 2:32 AM >> From: eliot.miranda(a)gmail.com >> To: henry <henry(a)callistohouse.club> >> Marcus Denker <marcus.denker(a)inria.fr>, Pharo Development List <pharo-dev(a)lists.pharo.org>, Squeak Virtual Machine Development Discussion <vm-dev(a)lists.squeakfoundation.org> >> >> Hi Henry, >> >> On Wed, Aug 16, 2017 at 6:33 PM, henry <henry(a)callistohouse.club> wrote: >> >>> That is good news, that it is due to this code doing funniness than a VM issue. This code trying to bring asynchrony within a synchronous environment brings new issues. >>> >>> What do you think that right solution is to the issue of a call expected to be immediate, change out to go eventual until the arguments resolve? >> >> I'm not informed enough to know. One could implement mustBeBoolean in the ERef hierarchy and resolve the promise before going on. One could rely on the mustBeBooleanMagic: if one wanted a fully lazy system. I don't know the trade-offs between the two. I do know that while the miustBeBooleanMagic: solution is cool and fun it is extremely slow. So if performance is an issue use the first approach. >> >>> How can it be structured correctly on the stack without generic functions? I think with the double dispatch of an eventual but I have not spend much time in this particular area. >> >> Yes that's an issue There is already a problem with #==. It needs to be symmetric for correctness. >> >>> Preventing the vm from crashing would be a good interim step but even here I am not sure how to go about crafting a solution. >> >> Well, the issue is simply that the wrong pc is chosen for the continuation after the mustBeBoolean. I'm sure the right answer is straight-forward to obtain. >> >>> Thank you for investigating this. >> >> You're welcome. >> >>> - HH >>> >>> On Wed, Aug 16, 2017 at 20:46, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: >>> >>>> Hi Henry, Hi Marcus, >>>> >>>> On Sun, Aug 13, 2017 at 5:08 AM, henry <henry(a)callistohouse.club> wrote: >>>> >>>>> Hi all. I was testing with this eventual_test package and it blows up the pharo 6.1 vm. I'd welcome pointers >>>>> >>>>> http://www.squeaksource.com/TurquoiseTesting.html >>>>> >>>>> - HH >>>> >>>> I took a look at this and I think you've found a bug in the mustBeBooleanMagic: code. What's happening is a mustBeBoolean in Integer>>* due to evaluating >>>> 10 * 42 eventual >>>> in RefsTest>>testFailureArithmeticPrimitivesWithPromiseArgument >>>> >>>> Since 42 eventual is a NearERef the SmallInteger>>* primitive fails and does ^super * anInteger (where anInteger is the NearERef). So that evaluates Integer>>* >>>> >>>> Integer>>* aNumber >>>> "Refer to the comment in Number * " >>>> aNumber isInteger ifTrue: >>>> [^ self digitMultiply: aNumber >>>> neg: self negative ~~ aNumber negative]. >>>> ^ aNumber adaptToInteger: self andSend: #* >>>> >>>> aNumber, being a NearERef, answers a PromiseERef for the isInteger send, and this provokes a mustBeBoolean for the isInteger ifTrue: [... >>>> >>>> After the mustBeBooleanMagic: the stack looks wrong. The activation of Integer>>*, which is about to do >>>> ^ aNumber adaptToInteger: self andSend: #* >>>> does not have enough items on the stack. Instead of containing >>>> a NearERef (for 42) >>>> 10 >>>> #* >>>> it contains >>>> a PromiseERef (for 42 eventual isInteger) >>>> >>>> and the send of #adaptToInteger:andSend: ends up taking more form the stack than the VM can handle and it crashes. The bug appears to be with the use of sendNode irInstruction nextBytecodeOffsetAfterJump in Object>>mustBeBooleanMagic: since execution should resume at bytecode 55 below, but does so at bytecode 57 >>>> >>>> 41 <10> pushTemp: 0 >>>> 42 <D0> send: isInteger >>>> 43 <AC 09> jumpFalse: 54 >>>> 45 <70> self >>>> 46 <10> pushTemp: 0 >>>> 47 <70> self >>>> 48 <D1> send: negative >>>> 49 <10> pushTemp: 0 >>>> 50 <D1> send: negative >>>> 51 <E2> send: ~~ >>>> 52 <F3> send: digitMultiply:neg: >>>> 53 <7C> returnTop >>>> 54 <10> pushTemp: 0 >>>> 55 <70> self >>>> 56 <24> pushConstant: #* >>>> 57 <F5> send: adaptToInteger:andSend: >>>> 58 <7C> returnTop >>>> >>>> So the positioning of the context's pc must be before any argument marshaling for the next send, not simply the send itself. >>>> >>>> Put a breakpoint at the end of Object>>mustBeBooleanMagic: and add initlaPC and resumePC temporaries at the beginning and capture them via >>>> initialPC := context pc. >>>> at the beginning and then >>>> context pc: (resumePC := sendNode irInstruction nextBytecodeOffsetAfterJump) >>>> to see what I'm seeing. >>>> >>>> Phew. Glad it's not a VM bug :-) >>>> >>>> HTH >>>> _,,,^..^,,,_ >>>> best, Eliot >> >> -- >> _,,,^..^,,,_ >> best, Eliot

Aug. 17, 2017