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

Re: [Pharo-dev] Happy new year!

by Stephane Ducasse

Thanks! I wish a lot of success and health to everybody. I like to think that because we are a community we are a lot more powerful than alone. So I wish you also a lot of fruitful collaborations. And I'm confident that 2019 will be even better than 2018. Stef On Mon, Dec 31, 2018 at 8:49 PM Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > > > > > On 31 Dec 2018, at 19:02, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > > > > Hi list, > > > > Just that. > > I wish you all have a happy new year, and may it be even better than this one :) > > > > Esteban > > Yes, I wish everybody all the best for 2019 ! > > Sven

Dec. 31, 2018

Re: [Pharo-dev] Happy new year!

by Sven Van Caekenberghe

> On 31 Dec 2018, at 19:02, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > > Hi list, > > Just that. > I wish you all have a happy new year, and may it be even better than this one :) > > Esteban Yes, I wish everybody all the best for 2019 ! Sven

Dec. 31, 2018

Happy new year!

by Esteban Lorenzano

Hi list, Just that. I wish you all have a happy new year, and may it be even better than this one :) Esteban

Dec. 31, 2018

Re: [Pharo-dev] New book: Pharo with Style

by Benoit St-Jean

Besides, I forgot to add one comment : you should have guidelines for protocol naming.Â It's not critical per se but I find it quite annoying to look for stuff in "enumerating" when it's been put in "printing" !Â loll On 2018-12-31 03:51, Stephane Ducasse wrote: > Thanks! Thanks! > I will go over it (now laying on my back :(( stupid muscles strike back!) > > On Mon, Dec 31, 2018 at 2:18 AM Benoit St-Jean <bstjean(a)yahoo.com> wrote: >> On 2018-12-30 16:13, Stephane Ducasse wrote: >>> Hello Fellow Pharoers >>> >>> I'm happy to announce a new little book to improve the culture around Pharo. >>> I will revise it in the future so you can feel free to send feedback >>> and pull requests >>> to https://github.com/SquareBracketAssociates/Booklet-PharoWithStyle >>> >>> Stef >>> >>> "The best way to predict the future is to invent" so I do it. >> StÃ©phane, >> >> You'll find, attached, a revised PDF version with my comments. >> >> >> >> -- >> ----------------- >> BenoÃ®t St-Jean >> Yahoo! Messenger: bstjean >> Twitter: @BenLeChialeux >> Pinterest: benoitstjean >> Instagram: Chef_Benito >> IRC: lamneth >> Blogue: endormitoire.wordpress.com >> "A standpoint is an intellectual horizon of radius zero". (A. Einstein) >> -- ----------------- BenoÃ®t St-Jean Yahoo! Messenger: bstjean Twitter: @BenLeChialeux Pinterest: benoitstjean Instagram: Chef_Benito IRC: lamneth Blogue: endormitoire.wordpress.com "A standpoint is an intellectual horizon of radius zero". (A. Einstein)

Dec. 31, 2018

Re: [Pharo-dev] New book: Pharo with Style

by Stephane Ducasse

Thanks! Thanks! I will go over it (now laying on my back :(( stupid muscles strike back!) On Mon, Dec 31, 2018 at 2:18 AM Benoit St-Jean <bstjean(a)yahoo.com> wrote: > > On 2018-12-30 16:13, Stephane Ducasse wrote: > > Hello Fellow Pharoers > > > > I'm happy to announce a new little book to improve the culture around Pharo. > > I will revise it in the future so you can feel free to send feedback > > and pull requests > > to https://github.com/SquareBracketAssociates/Booklet-PharoWithStyle > > > > Stef > > > > "The best way to predict the future is to invent" so I do it. > > StÃ©phane, > > You'll find, attached, a revised PDF version with my comments. > > > > -- > ----------------- > BenoÃ®t St-Jean > Yahoo! Messenger: bstjean > Twitter: @BenLeChialeux > Pinterest: benoitstjean > Instagram: Chef_Benito > IRC: lamneth > Blogue: endormitoire.wordpress.com > "A standpoint is an intellectual horizon of radius zero". (A. Einstein) >

Dec. 31, 2018

Esteban's ChangeLog week of 24 December 2018

by estebanlm＠gmail.com

Hello! This is my weekly ChangeLog, from 24 December 2018 to 30 December 2018. You can see it in a better format by going here: http://log.smallworks.eu/web/search?from=24/12/2018&to=30/12/2018 ChangeLog ========= 27 December 2018: ----------------- * Opened Pharo8.0 development * branch was already opened by Stef :) * opened issue tracker * updated documents to point to it * sent mails to list TODO: Update videos (we needed new ones anyway) cheers! Esteban

Dec. 31, 2018

Re: [Pharo-dev] New book: Pharo with Style

by Benoit St-Jean

On 2018-12-30 16:13, Stephane Ducasse wrote: > Hello Fellow Pharoers > > I'm happy to announce a new little book to improve the culture around Pharo. > I will revise it in the future so you can feel free to send feedback > and pull requests > to https://github.com/SquareBracketAssociates/Booklet-PharoWithStyle > > Stef > > "The best way to predict the future is to invent" so I do it. StÃ©phane, You'll find, attached, a revised PDF version with my comments. -- ----------------- BenoÃ®t St-Jean Yahoo! Messenger: bstjean Twitter: @BenLeChialeux Pinterest: benoitstjean Instagram: Chef_Benito IRC: lamneth Blogue: endormitoire.wordpress.com "A standpoint is an intellectual horizon of radius zero". (A. Einstein)

Dec. 31, 2018

New book: Pharo with Style

by Stephane Ducasse

Hello Fellow Pharoers I'm happy to announce a new little book to improve the culture around Pharo. I will revise it in the future so you can feel free to send feedback and pull requests to https://github.com/SquareBracketAssociates/Booklet-PharoWithStyle Stef "The best way to predict the future is to invent" so I do it.

Dec. 30, 2018

[Pharo 7.0] Build #91: Revert "21876 Re-evaluating of class definition with slots cleans the class instance variables"

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

There is a new Pharo build available! The status of the build #91 was: FAILURE. The Pull Request #2145 was integrated: "Revert "21876 Re-evaluating of class definition with slots cleans the class instance variables"" Pull request url: https://github.com/pharo-project/pharo/pull/2145 Issue Url: https://pharo.fogbugz.com/f/cases/revert Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Dec. 30, 2018

Re: [Pharo-dev] About contribution process, people participation and communication (WAS: Re: [ANN] Pharo 8.0 development started)

by Ben Coman

On Sun, 30 Dec 2018 at 23:28, Esteban Lorenzano via Pharo-dev < pharo-dev(a)lists.pharo.org> wrote: > > Now, while the general direction was explained, I think I failed to > communicate several things. > For what I can think at this moment (for sure there are a lot more): > > - I failed to communicate that opening Pharo 8.0 branch didnât mean > closing Pharo 7.0 development, just to allow people doing big changes to > merge them. > - I failed to communicate correctly that having a release candidate (rc1) > meant âcode freezeâ (and then forbidding new changes except bug fixing). > Thanks for acknowledging this Esteban. In spite of the communication issue, the point I'd make in support of this arrangement is that historically we've done poorly with code-freezes, or even the lesser strength feature-freezes leading up to a release. A code freeze can be discouraging when integration of new features are delayed and can weaken such the code freeze. Opening the next-version-dev branch when the current-version freezes for release-candidate seems to facilitate pre-release stability - though the risk though of mind-share drifting to the next-version-dev branch needs to be managed. cheers -ben

Dec. 30, 2018

Re: [Pharo-dev] [ANN] Pharo 8.0 development started

by Sean P. DeNigris

Pharo Smalltalk Developers mailing list wrote > Iâm on holidays until 7/01 :P Esteban, thank you for all your incredible work on all these simultaneous big, hard problems! Now stop sending mails and go enjoy your holiday ;-) ----- Cheers, Sean -- Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html

Dec. 30, 2018

[Pharo 7.0] Build #90: 22855-Revert-PluggableTextMorph-changes

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

There is a new Pharo build available! The status of the build #90 was: SUCCESS. The Pull Request #2144 was integrated: "22855-Revert-PluggableTextMorph-changes" Pull request url: https://github.com/pharo-project/pharo/pull/2144 Issue Url: https://pharo.fogbugz.com/f/cases/22855 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Dec. 30, 2018

About contribution process, people participation and communication (WAS: Re: [Pharo-dev] [ANN] Pharo 8.0 development started)

by Esteban Lorenzano

Hi Torsten (again), What I see in your mails, and what I think is most important to discuss, is a subjacent critique about the way we communicate our changes. And maybe more than that: a disagreement about the general direction of changes in process. While I recognise we can communicate better (and we take any criticism in that sense as a remark of our need to improve), is not fair to say that we did not announce what we were doing: - it is told and very discussed the fact that we were going to a git based process and supported by github. This *was* discussed and announced. And we worked a lot last year to make it possible (and is the main reason why we delayed P7 release). - We announced that we were moving our issue tracker to GitHub at least 6-8 months before (in fact we were ready to do it in that moment but we delayed it âfor Pharo8â to avoid transition problems. - We announced that we wanted to have at least two branches opened at same time, and to make that possible. Now, while the general direction was explained, I think I failed to communicate several things. For what I can think at this moment (for sure there are a lot more): - I failed to communicate that opening Pharo 8.0 branch didnât mean closing Pharo 7.0 development, just to allow people doing big changes to merge them. - I failed to communicate correctly that having a release candidate (rc1) meant âcode freezeâ (and then forbidding new changes except bug fixing). New process is different than old process. And we had transition problems (and we still have some). But new process is a lot better than old one. Is faster, shorter and it allows us to have different branches alive :) But well, letâs focus in the positive: We are improving in an area that is always hard, which is process. Iâm deeply sorry if someone felt alienated in the process of changing process (I know for windows users it was a problem until we introduced Tonel, for example). And specially, we are willing to improve. So, Iâd like to see your suggestions (and any one else with ideas) on how can we improve both process and communication. Esteban

Dec. 30, 2018

Re: [Pharo-dev] [ANN] Pharo 8.0 development started

by Esteban Lorenzano

> On 27 Dec 2018, at 21:13, Torsten Bergmann <astares(a)gmx.de> wrote: > > and > > 11. There is no https://get.pharo.org/80 yet â¦ Because there is no release! As I said before, most of yours concerns are because I failed to explain correctly the purpose of a Pharo 8.0 branch opening. Esteban > > Bye > T. >

Dec. 30, 2018

Re: [Pharo-dev] [ANN] Pharo 8.0 development started

by Esteban Lorenzano

Hi Torsten, I think most of your concerns are due a miss-explanation about what it means opening P8 branch. It does not means we are releasing P7 or stopping to work on it. It means people can now do pull requests that would not be accepted for Pharo 7.0 in a different branch. Pharo 7.0 is not done and we are not switching to Pharo 8.0 now. This is just to allow some changes to be integrated without restricting people contributions just because P7 release is stuck because other problems. > On 27 Dec 2018, at 21:06, Torsten Bergmann <astares(a)gmx.de> wrote: > > Hi Esteban, > > you know I'm neither shy on contributing nor doing any work for Pharo but personally I think we open Pharo 8 too early and should better focus our efforts more > on finalizing P7 (see below) instead of opening the next construction site. > > Things were already shaky and sometimes painful with P7 - nonetheless I managed to get 762 commits into it. Often simple or boring PR's just to get packages, classes, methods > in shape and clean up. Funny enough I can now say I'm on top of https://github.com/pharo-project/pharo/graphs/contributors ;) > > I had a hard time finding out how things work in the new git/pharo/externally managed projects combination - sometimes also with broken or unfinished tools. A newly opened > P8 so early adds even more on top... > > Several things directly came into my mind: > > 1. http://bugs.pharo.org now points to nirvana now This is like that since a lot (not to say it shouldnât be fixed, but to explain that is no blocker). That address needs to be redirected or decommissioned. > > 2. http://ci.pharo.org point to nirvana now as well Same. I think this is due some migration in INRIA servers, In any case, this is orthogonal. > > 3. It's unclear to me what will happen to the bugtracker mailinglist archive. Currently I often use it to stay informed about our changes. > Will it stop in december? > > https://lists.gforge.inria.fr/pipermail/pharo-bugtracker/ <https://lists.gforge.inria.fr/pipermail/pharo-bugtracker/> We should redirect pharo issues to them. > > 4. The CI for Pharo 7 was not green in most of the latest commits ... and situation for Pharo 8 is not even better now: RED all over on > > https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2… <https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…> Is a problem in our CI, not in the image it self. Iâm not happy with it, but again this is orthogonal. > 5. We still have dirty packages in Pharo 7 - the last remaining issue here > https://github.com/pharo-ide/Calypso/issues/386 > is still not solved and there was no reaction on Discord after reminding it twice. This needs to be solved, yes. There was not reaction because mostly I was not around ;) > > 6. Calypso still has hard issue in Pharo 7 - most of them already fixed in Calypso project. > > But integration of the new Calypso version is still pending https://github.com/pharo-project/pharo/pull/2115 Yes, we know :) > > Nonetheless we already switch to P8? We didnât switch to P8. We open P8 dev branch. > > 7. A change done lately (around 17.12.) was resetting the build numbers - so for whatever strange reason we started with 1 again > althoug we were already at Build 1416 for Pharo 7 with all the integrations. > > https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2… > > This build number issue was not yet fixed although this is a serious issue to compare image buils or be able to download using Launcher. Build numbers are created /per branch/, not by job. This is a problem indeed but we do not have a solution for it. Real solution will be to change launcher to not consider build number (but take build date, we donât know) > > Nonetheless we already switch to P8? Again, we didnât switch, we just opened. > > 8. Lately we switched the branches from "development" to "Pharo7.0" and now also "Pharo8.0". This was also just announced - without any discussion > in advance forcing people to resetup their tools and local repos. > > This change is still not event reflected in the contribution guideline ... but we already switch to Pharo 8 The full purpose of the change was to be able to have two (or more) branches opened simultaneously. And yes, there will be a Pharo8.0 (and eventually a Pharo9.0), etc. branchesâ¦ > > 9. We still have lots of important and must-fix cases for Pharo 7 > https://pharo.fogbugz.com/f/filters/1412/7-0-All <https://pharo.fogbugz.com/f/filters/1412/7-0-All> I know. Iâm almost the only one working on them. > > 10. There was nothing said about backporting strategy between the new P8 and P7 nowâ¦ It was said. Backport will happen by doing pull requests to the different, active, branch. Frontport (from P7 to P8) will be made in the same way, in regular basis. > > > To me it would already help a little bit to clarify the above raised points and get a more detailed info about the next P7 steps towards the release. We still not release P7!. To do that, we need several things to align before: - 64bit windows vm - new freetype2 version (2.9.1) in all platforms. - Calypso glitches - Some other cleanings (I do not remember exactly right now, Iâm on holidays until 7/01 :P) > > Independent from that I fear we constantly decouple more and more people with too many process and contribution scheme changes at once. From the discussions > on Discord I already see many people struggle - and often not only the beginners. People struggle always. We try to help, and to simplify. Some times with better results than others. But there is no such thing as an âeffortless contributionâ, it was not like that before and it is not like that now. But I will write another mail about this later. Cheers! Esteban > > Bye > T. >

Dec. 30, 2018

Re: [Pharo-dev] [Moose-dev] glamorous toolkit: v0.4.0

by Tudor Girba

Hi, Thanks for the link. For some strange reason, I do not see the linked email in my inbox. I am happy to hear that you could install GT. > * The new interfaces and some demo of the graphical elements look > pretty good > * After just some operations including window resizing I just get the > Red Window of Death [1](https://i.imgur.com/Cbx7uyH.png). Indeed, that is a known problem: https://github.com/feenkcom/gtoolkit/issues/64 > * I like the little triangles to expand thing in the document and the > run buttons for embedded code, and the "embeddability" of elements > in the document in a tree like fashion, which of course could lead > to documents that embed pieces of documents, which embed pieces of > documentsâ¦ But the dual panel view of code in one side with > results in the right panel of old GT didn't tend to create such > "recursion". This dual modal view is the same of > Atom[2](https://is.gd/kegaso) and CodiMD[3](https://is.gd/wudugi) > for interactive documentation and I would like to see examples more > in that line... but I don't know how it suits the philosophy behind > Documenter, which seems more aligned to a modal non dual view of the > document where you enter into edit mode once you click a piece of > the document and into a view mode once you are out of it (instead of > the proposed dual view). Would be nice to see is such dual view can > be used to directly operate on the rendered view and see changes in > the markup (i.e resizing an image in the rendered view changes the > value on the edit view). Interesting observation. The linked tools as all other notebook technologies I saw rely on two distinct modes for edit and view that reside in two distinct widgets (editor and viewer). They do that because they simply cannot have it in one. Because of the design of Bloc we are not constrained to that. Instead, we build a seamless interface that is both optimized for viewing, and for editing with live preview that does not rely on an explicit render button. This approach enables direct manipulation without friction, and we think this is a significant advancement in this space. About the remark related "to documents that embed pieces of documents, which embed pieces of documentsâ: It is indeed possible to embed documents in documents, but I am not sure I understand where you see the issue appearing. Could you detail this part? > * I like the different view that a document can have, markup wise: > Pillar, Markdown, LaTeX, HTML, DeckJS AsciiDoc as is demoed in the > authoring part [4](https://i.imgur.com/Jc1T5Rm.png). Interestingly, those extensions exist in the old Inspector as well. > * Its difficult to travel between the panels of a playground. > Previously you just make click in the lower circle representing the > panel you want to go at it was done > [5](https://i.imgur.com/4CDAM2o.png), but now clicking on the upper > rectangle representing such panel has no effect > [6](https://i.imgur.com/8Obo3Ct.png). For now, you have to rely on horizontal scrolling using a trackpad or mouse. Alternatively, Shift+scroll should also work. The upper part is not yet ready. > * Auto-completion and shortcuts for selecting text doesn't work well > on code cells of the new playground. Selecting whole words with Ctrl > arrow doesn't work, neither using down arrows to choose from > suggestions and even you can end with previous suggestions floating > around your playground [7](https://i.imgur.com/4awyIft.png) > [8](https://i.imgur.com/7qXc64b.png). Indeed. These are known issues that we will tackle soon. > * The default data science example didn't work at all > [8](https://i.imgur.com/YhNb8el.png) Nice catch. Thanks. The path of the file is incorrect when the image is copied. >> Now, a clarification. The old GT was produced over a period of 4 years >> by an open-source team. The project had its own identity, and in 2014 >> the core of it was first integrated in Pharo. I say the core of it, >> because the visual part and other libraries are not in Pharo today. >> >> The full potential is found in Moose. In any case, during this >> process, GT got to be identified with Pharo and that was a good thing. >> The new GT is a product produced by feenk, a company. Much of the >> original team is still active in the new version, but now we commit to >> our product in a different way. The product is free and open-source, >> but itâs still a product with an identity and a goal. At present time, >> both the team, identity and goal are different than those of Pharo. >> >> Our goal is to offer a fundamentally new alternative to program >> (including comparing to what is possible now in Pharo). We are not >> looking for marginal improvements, and we are not aiming at backward >> compatibility. > I used Moose to build the first Grafoscopio versions, but there was a > lot of stuff that was related with software analysis that I didn't > really need for reproducible interactive documentation and publishing > nor for data science, activism and storytelling. So once old GT was > integrated into Pharo with Spec I used a more minimal setup to deliver a > more focused experience. > > I think that most times this relationship between Pharo and Moose can be > of creative tension, one pushing the boundaries and the other offering a > more stable experience where the innovations of the former are > integrated and debugged. But even after using Moose as a fully > integrated vision of what old GT have to offer in the back and front > end, I didn't see any migration path from previous Moose with the old GT > to the current GT, which is kind of worrisome. I understand the idea of > forks in FLOSS as a way of dealing with politics behind the FLOSS > movement and the relationship between different visions and actors > (individuals, communities, enterprises, foundations, associations and so > on). It has happened before with Squeak, Pharo and Cuis and I'm fine > with that. And I understand that a healthy relationship with the past > means sometimes to break with it and jump into the future. > > That's why I think that the role of for profit and non for profit > institutions is to balance a sense of momentum and stability around > FLOSS. I would like to see a more clear road map for GT, knowing ahead > where backward compatibility will be broken and why, which are the > visions and, more importantly, how to participate and where are the > boundaries. These are difficult tasks, but if the participation and > boundaries are explored collectively, you can also know about the first > ones (visions, versions, forks, compatibility). In that sense I think > that Pharo is putting a good example: we have a clear road map document > and participation process in the public repositories, there are public > channels for users and developers and the private companies know about > them, so they can put the boundaries about what is going to be done in > the open, with the community, and what is to be kept closed inside > company's frontiers and channels and the company's own velocity. I don't > know if Feenk is planing something similar for its new vision, product > and identity, and I don't know if the new alternative will have its own > non-profit organizations as a neutral entity for all players using GT, > but would be good to know about that, not because there are not people > willing to jump into the future, but we would like to know to which > future we're jumping on. Without that I think that is a safer bet for > myself to rely on Pharo and see how migration paths could ensure > compatibility with my own past and the one of my local community using > Pharo and GT based tools. I hope that the open source nature of both > products (Pharo and new GT) will ease the cross-pollination of the more > interesting ideas, even without sharing code, visions or UI. We do not regard our work as an evolution, and we are not concerned with backwards compatibility. We are not trying to be completely different to what we had before, but being compatible is simply not a goal. For example, extending oldInspector is usually a matter of a dozen lines. Extending the new Inspector works in a similar way, but with a slightly different API that is needed because of the new infrastructure. The migration is not a pain, and it can happen seamlessly as I described in the mail to Luke. I understand how from your point of view as a user of Pharo and oldGT you regard backward compatibility as important. However, we look at things differently. We think that development can be enhanced both from an efficiency and from a happiness point of view with a significant degree. When something like this is possible, the opportunities are different, too. For example, backward compatibility is about limiting costs. However, when the profit promise can be large, some costs can be worthwhile and are to be considered investments. What do we mean by profit? For example, what would it be worth for a company to have the non-technical people literally pair and understand the internal details of the domain model? Compared to what exists now, that can be invaluable and we think that following moldable development this will be a natural by product. Another example: what would it worth for a developer of a library to build a live documentation with a marginal effort that simply leverages the testing effort? It can be invaluable, and we think this is trivially possible. About the roadmap, here it is: we aim to build a complete development environment that will enable moldable development. We understand how this can appear vague. I think itâs not because I and my colleagues talk about it since many years now. People pay little attention, so now we set ourselves to deliver a concrete incarnation of what we think the future should look like. We set to create something that does not exist in other parts, and we simply do not quite know how this will look like in details. For example, we do know that we want to build a Coder or a Debugger, we even have advanced ideas and implementations, but we do not know exactly how it will look like and because of that we also do not quite know how long it will take. We have a particular way of approaching development that relies on fast feedback and storytelling, and at the end we always get surprised of where the journey takes us. For example, the current state of Documenter was simply difficult to imagine even 4 months ago, and in the process we threw away more code than is now released. So, we will not detail the concrete steps because we do not work like that. We do have a clear vision of what we think software development should be, and we will put forward our guiding principles shortly. About the governance process: GT is built by feenk and will continue to be so for the foreseeable future. We put things that we create in the open, we do so for free, and we welcome people to engage with us. >> To build this alternative we invested in a whole new stack. That is >> not a tiny challenge and getting it right requires many iterations and >> feedback. We say we are in alpha not because of inconveniences of >> installation but because we are still very much developing the product. >> >> We announced the first alpha version in September and since then much >> has changed. At present time, we did manage to reach a situation where >> downloading the distribution should run on Mac, Linux and Windows. >> Even so, the current version is only for people that do want to try >> knowing that there will be hurdles. > > I think that not only installation inconveniences is related alpha, but > also this jumping from old GT to new one without a clear migration path > (as is expected from alpha software and processes). I'm fine with that > too, but I think that once the new GT reaches beta status the backward > compatibility should be more important and meanwhile the non regard of > that should be stated more promptly for previous and future GT users. I > imagine that, at some point Feenk will provide its users and customers > with clear support and migration paths regarding its open source > products (kind of what happens with Canonical and the Long Term Support > versions of Ubuntu). As mentioned above, our focus is to build a new experience. It is likely that a typical Pharo user will not have much issues adapting to the new interface. A developer that depended on the old APIs will be somewhat impacted, but we do not expect a too large effort will be required to adopt the new world. Nevertheless, if itâs stability and predictability you are looking for, it is best to wait for now. >> A word about the user experience. The current version runs inside the >> Pharo UI because we need to bootstrap. But, our goal is to build a >> complete IDE on the new stack. If you want to judge the user >> experience, it is only meaningful to do it within the GT windows, and >> not by comparing it with the rest of the existing Pharo UI. >> >> Does this clarify the situation? > Yes, it does. It seems that a fork is coming, at least UI wise regarding > Pharo and new GT, but if the community knows about it, I'm fine with > that. I think this thread also clarifies what active users of old GT > will expect from upcoming versions of new (non alpha) GT regarding > compatibility, open processes, visions and so on. Hopefully we will > reach that place together. I do not think a new piece of code should be called a fork. At this point in time, GT and everything it comes with, loads cleanly in Pharo 7. Cheers, Doru > On Dec 29, 2018, at 5:10 PM, Offray Vladimir Luna CÃ¡rdenas <offray.luna(a)mutabit.com> wrote: > > Hi Doru, > > This one is still pending: > > https://www.list.inf.unibe.ch/pipermail/moose-dev/2018-December/027542.html > > Of course we have slow days at end of year and I don't expect immediate > answer, but now that discussion was active is good to point some pending > conversation, even to be taken after holidays. > > Cheers, > > Offray > > On 29/12/18 6:38, Tudor Girba wrote: >> Hi Offray, >> >> I believe I replied to all your emails. If I missed one, please point me to it. >> >> Cheers, >> Doru >> >> >>> On Dec 28, 2018, at 5:12 PM, Offray Vladimir Luna CÃ¡rdenas <offray.luna(a)mutabit.com> wrote: >>> >>> >>> On 28/12/18 8:03, Tudor Girba wrote: >>>>> On Dec 28, 2018, at 1:08 PM, Kjell Godo <squeaklist(a)gmail.com> wrote: >>>>> >>>>> WOW >>>> :) >>>> >>>> What part of it do you like? >>>> >>>> Cheers, >>>> Doru >>> And which parts you don't? >>> >>> I wrote a long mail regarding good and no so good parts of the new GT >>> experience, including features possible forks, that I hope will be >>> answered also in detail, to keep the big picture. >>> >>> Cheers, >>> >>> Offray >>> >>> >>> >> -- >> www.feenk.com >> >> "You can inspect and adapt only what is explicit." >> >> -- www.feenk.com "No matter how many recipes we know, we still value a chef."

Dec. 29, 2018

[Pharo 7.0] Build #89: 22842-Fix-externalBrowserTest

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

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

Dec. 29, 2018

Re: [Pharo-dev] [Pharo 7.0] Build #88: 22827-Update-Calypso-Version

by Denis Kudriashov

And now we have Breakpoints browser in image (from Debugging menu) ÑÐ±, 29 Ð´ÐµÐº. 2018 Ð³. Ð² 14:22, <ci-pharo-ci-jenkins2(a)inria.fr>: > There is a new Pharo build available! > > The status of the build #88 was: FAILURE. > > The Pull Request #2115 was integrated: "22827-Update-Calypso-Version" > Pull request url: https://github.com/pharo-project/pharo/pull/2115 > > Issue Url: https://pharo.fogbugz.com/f/cases/22827 > Build Url: > https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2… >

Dec. 29, 2018

[Pharo 7.0] Build #88: 22827-Update-Calypso-Version

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

There is a new Pharo build available! The status of the build #88 was: FAILURE. The Pull Request #2115 was integrated: "22827-Update-Calypso-Version" Pull request url: https://github.com/pharo-project/pharo/pull/2115 Issue Url: https://pharo.fogbugz.com/f/cases/22827 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Dec. 29, 2018

[Pharo 7.0] Build #87: Improving the script to detect the version of the build.

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

There is a new Pharo build available! The status of the build #87 was: FAILURE. The Pull Request #2134 was integrated: "Improving the script to detect the version of the build." Pull request url: https://github.com/pharo-project/pharo/pull/2134 Issue Url: https://pharo.fogbugz.com/f/cases/improving Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Dec. 29, 2018

[Pharo 7.0] Build #86: Bottom21

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

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

Dec. 29, 2018

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

by Tudor Girba

Great work! Doru > On Dec 27, 2018, at 10:32 AM, Jan van de Sandt <jvdsandt(a)gmail.com> wrote: > > Hi, > > Last month Amazon extended their serverless runtime platform AWS Lambda with support for custom runtimes. I created a Pharo Lambda Runtime so now we can implement Lambda functions in Smalltalk and easily deploy them on the Lambda platform. Lamba has quite a large "free-tier", more than enough to do some experiments and to host small applications for free. > > See the GitHub project for more details https://github.com/jvdsandt/pharo-aws-toolbox > > Cheers, > Jan. -- www.feenk.com "You can inspect and adapt only what is explicit."

Dec. 29, 2018

Re: [Pharo-dev] [Moose-dev] glamorous toolkit: v0.4.0

by Tudor Girba

Hi Offray, I believe I replied to all your emails. If I missed one, please point me to it. Cheers, Doru > On Dec 28, 2018, at 5:12 PM, Offray Vladimir Luna CÃ¡rdenas <offray.luna(a)mutabit.com> wrote: > > > On 28/12/18 8:03, Tudor Girba wrote: >>> On Dec 28, 2018, at 1:08 PM, Kjell Godo <squeaklist(a)gmail.com> wrote: >>> >>> WOW >> :) >> >> What part of it do you like? >> >> Cheers, >> Doru > > And which parts you don't? > > I wrote a long mail regarding good and no so good parts of the new GT > experience, including features possible forks, that I hope will be > answered also in detail, to keep the big picture. > > Cheers, > > Offray > > > -- www.feenk.com "You can inspect and adapt only what is explicit."

Dec. 29, 2018

[Pharo 7.0] Build #85: 22848-Patch-to-avoid-breaking-iceberg

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

There is a new Pharo build available! The status of the build #85 was: FAILURE. The Pull Request #2132 was integrated: "22848-Patch-to-avoid-breaking-iceberg" Pull request url: https://github.com/pharo-project/pharo/pull/2132 Issue Url: https://pharo.fogbugz.com/f/cases/22848 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Dec. 28, 2018

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

by Tim Mackinnon

Ah - so is the HANDLER variable set via the AWS console? (If so, then Iâd agree that using the env var makes more sense). It also sounds like NeoJson makes sense for the mapping - I hadnât needed it before in my usage - I donât think itâs very heavy weight anyway. For debugging, the serialisation of the stack to a bucket is so cool (kudos to Fuel for that), but cloudwatch is a useful basic tool and it does let you hook up to things like data dog etc. so we fit easily into the cloud eco system. I need to get things up and running again and will report back. Thanks again. Tim Sent from my iPhone > On 28 Dec 2018, at 17:30, Jan van de Sandt <jvdsandt(a)gmail.com> wrote: > > Hi Tim, > >> On Fri, Dec 28, 2018 at 4:49 PM Tim Mackinnon <tim(a)testit.works> wrote: >> Hi Jan - reading through your docs, this looks very promising as I hadnât got as far as using the api gateway - I was just connecting to the internal Alexa service. >> >> One thing I didnât quite understand - you mention specifying a HANDLER as an env variable, but your example description doesnât seem to show where that is set? Is it in the bootstrap file (also is that bootrap.sh or just simply bootstrap? > > Up til now I have configured my Lambda functions mostly via the AWS Console. When you create your function you must upload your code, specify the type of runtime and give the name of the handler. For a Java runtime this is the name of the main class, so for the Smalltalk implementation I choose something similar. If you want you can leave this item empty or set it to "Provided" and just hardcode the startup class in the image or in the bootstrap file. > >> And are there any file attributes to set on that file?). It strikes me that rather than using an env variable - why donât you specify the handler class when you invoke the image as the last command line option? (That is what I did in my example - or is it faster to query an env variable? Personally I find it easier to see it more explicitly on the command line). >> >> I also notice you include NeoJson - did you need that? I found that the default Ston reader was more than adequate for reading the json that was sent over (and so itâs one less pre-req). >> > With NeoJSON you can create mappings to serialize/deserialize custom Smalltalk classes to Json. I use this functionality in the CloudWatch-Logs interface to handle the request and response objects. I don't think this is possible with STON. > >> I havenât yet fully understood the runtime layer - is this simply a zip file with the vm + files and without the image? Previously I had to add all of that in the zip I uploaded for each function, but this sounds like it simplifies things a lot. Do you have a script you used to create that - I ask as I found that trimming down the size of that made a difference to load times for Alexa (eg there are lots of sound and graphics dllâs you can remove - which I have in my script, and possibly, I could add to what you have done). > > Yes, the layers are a great new feature. My layer just includes a standard Pharo 64 bits VM without any additions or removals. I made this one by hand, a script would be a better idea! You can remove shared libraries that you don't need. I think the most important thing is that the image does not load/initialize any unnecessary libraries. >> >> Equally, I also figured out the command line fu for uploading and registering your Lamba so it works in a ci - this might also be worthy of inclusion. >> > Yes, a CI job that can build a 'deployment' image and that can upload this image to AWS Lambda would be a great feature! > >> Anyway, lâll Give it a go and see how the results compare - it was surprisingly fast using the js shim - but this seems like a much better solution. >> >> Thanks for sharing - itâs an executing world. >> >> Tim >> > Thanks for your comments! > Jan. > >> >> >> >> Sent from my iPhone >>> On Fri, 28 Dec 2018, at 11:35 AM, Jan van de Sandt wrote: >>> Hi Tim, >>> >>> Yes, I read that you got Pharo working via the Javascript runtime. It should now be much easier and faster. >>> >>> I still have to figure out the best way to create a deployment image. With the new bootstrap/modular setup of Pharo 7 it should be possible to create a lean-and-mean runtime image that can run in the cheapest 128MB max. ram configuration. >>> >>> Jan. >>> >>> On Thu, Dec 27, 2018 at 2:18 PM Tim Mackinnon <tim(a)testit.works> wrote: >>> Cool - I was using a JS shim and had asked AWS many times why they couldnât open it up wider... >>> >>> Now Iâm back from my travels Iâll reincarnate my previous work and see how it works with this. I was looking forward to doing more with Lambda, so this is great timing. >>> >>> Tim >>> >>> Sent from my iPhone >>> >>>> On 27 Dec 2018, at 10:32, Jan van de Sandt <jvdsandt(a)gmail.com> wrote: >>>> Hi, >>>> >>>> Last month Amazon extended their serverless runtime platform AWS Lambda with support for custom runtimes. I created a Pharo Lambda Runtime so now we can implement Lambda functions in Smalltalk and easily deploy them on the Lambda platform. Lamba has quite a large "free-tier", more than enough to do some experiments and to host small applications for free. >>>> >>>> See the GitHub project for more details https://github.com/jvdsandt/pharo-aws-toolbox >>>> >>>> Cheers, >>>> Jan. >>

Dec. 28, 2018

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

by Jan van de Sandt

Hi Tim, On Fri, Dec 28, 2018 at 4:49 PM Tim Mackinnon <tim(a)testit.works> wrote: > Hi Jan - reading through your docs, this looks very promising as I hadnât > got as far as using the api gateway - I was just connecting to the internal > Alexa service. > > One thing I didnât quite understand - you mention specifying a HANDLER as > an env variable, but your example description doesnât seem to show where > that is set? Is it in the bootstrap file (also is that bootrap.sh or just > simply bootstrap? > Up til now I have configured my Lambda functions mostly via the AWS Console. When you create your function you must upload your code, specify the type of runtime and give the name of the handler. For a Java runtime this is the name of the main class, so for the Smalltalk implementation I choose something similar. If you want you can leave this item empty or set it to "Provided" and just hardcode the startup class in the image or in the bootstrap file. And are there any file attributes to set on that file?). It strikes me that > rather than using an env variable - why donât you specify the handler class > when you invoke the image as the last command line option? (That is what I > did in my example - or is it faster to query an env variable? Personally I > find it easier to see it more explicitly on the command line). > > I also notice you include NeoJson - did you need that? I found that the > default Ston reader was more than adequate for reading the json that was > sent over (and so itâs one less pre-req). > > With NeoJSON you can create mappings to serialize/deserialize custom Smalltalk classes to Json. I use this functionality in the CloudWatch-Logs interface to handle the request and response objects. I don't think this is possible with STON. > I havenât yet fully understood the runtime layer - is this simply a zip > file with the vm + files and without the image? Previously I had to add all > of that in the zip I uploaded for each function, but this sounds like it > simplifies things a lot. Do you have a script you used to create that - I > ask as I found that trimming down the size of that made a difference to > load times for Alexa (eg there are lots of sound and graphics dllâs you can > remove - which I have in my script, and possibly, I could add to what you > have done). > Yes, the layers are a great new feature. My layer just includes a standard Pharo 64 bits VM without any additions or removals. I made this one by hand, a script would be a better idea! You can remove shared libraries that you don't need. I think the most important thing is that the image does not load/initialize any unnecessary libraries. > > Equally, I also figured out the command line fu for uploading and > registering your Lamba so it works in a ci - this might also be worthy of > inclusion. > > Yes, a CI job that can build a 'deployment' image and that can upload this image to AWS Lambda would be a great feature! > Anyway, lâll Give it a go and see how the results compare - it was > surprisingly fast using the js shim - but this seems like a much better > solution. > > Thanks for sharing - itâs an executing world. > > Tim > > Thanks for your comments! Jan. > > > > Sent from my iPhone > On Fri, 28 Dec 2018, at 11:35 AM, Jan van de Sandt wrote: > > Hi Tim, > > Yes, I read that you got Pharo working via the Javascript runtime. It > should now be much easier and faster. > > I still have to figure out the best way to create a deployment image. With > the new bootstrap/modular setup of Pharo 7 it should be possible to create > a lean-and-mean runtime image that can run in the cheapest 128MB max. ram > configuration. > > Jan. > > On Thu, Dec 27, 2018 at 2:18 PM Tim Mackinnon <tim(a)testit.works> wrote: > > Cool - I was using a JS shim and had asked AWS many times why they > couldnât open it up wider... > > Now Iâm back from my travels Iâll reincarnate my previous work and see how > it works with this. I was looking forward to doing more with Lambda, so > this is great timing. > > Tim > > Sent from my iPhone > > On 27 Dec 2018, at 10:32, Jan van de Sandt <jvdsandt(a)gmail.com> wrote: > > Hi, > > Last month Amazon extended their serverless runtime platform AWS Lambda > with support for custom runtimes. I created a Pharo Lambda Runtime so now > we can implement Lambda functions in Smalltalk and easily deploy them on > the Lambda platform. Lamba has quite a large "free-tier", more than enough > to do some experiments and to host small applications for free. > > See the GitHub project for more details > https://github.com/jvdsandt/pharo-aws-toolbox > > Cheers, > Jan. > > >

Dec. 28, 2018

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

by Tim Mackinnon

Hi Jan - reading through your docs, this looks very promising as I hadnât got as far as using the api gateway - I was just connecting to the internal Alexa service. One thing I didnât quite understand - you mention specifying a HANDLER as an env variable, but your example description doesnât seem to show where that is set? Is it in the bootstrap file (also is that bootrap.sh or just simply bootstrap? And are there any file attributes to set on that file?). It strikes me that rather than using an env variable - why donât you specify the handler class when you invoke the image as the last command line option? (That is what I did in my example - or is it faster to query an env variable? Personally I find it easier to see it more explicitly on the command line). I also notice you include NeoJson - did you need that? I found that the default Ston reader was more than adequate for reading the json that was sent over (and so itâs one less pre-req). I havenât yet fully understood the runtime layer - is this simply a zip file with the vm + files and without the image? Previously I had to add all of that in the zip I uploaded for each function, but this sounds like it simplifies things a lot. Do you have a script you used to create that - I ask as I found that trimming down the size of that made a difference to load times for Alexa (eg there are lots of sound and graphics dllâs you can remove - which I have in my script, and possibley, I could add to what you have done). Equally, I also figured out the command line fu for uploading and registering your Lamba so it works in a ci - this might also be worthy of inclusion. Anyway, lâll Give it a go and see how the results compare - it was surprisingly fast using the js shim - but this seems like a much better solution. Thanks for sharing - itâs an executing world. Tim Sent from my iPhone > On Fri, 28 Dec 2018, at 11:35 AM, Jan van de Sandt wrote: > Hi Tim, > > Yes, I read that you got Pharo working via the Javascript runtime. It should now be much easier and faster. > > I still have to figure out the best way to create a deployment image. With the new bootstrap/modular setup of Pharo 7 it should be possible to create a lean-and-mean runtime image that can run in the cheapest 128MB max. ram configuration. > > Jan. > > On Thu, Dec 27, 2018 at 2:18 PM Tim Mackinnon <tim(a)testit.works> wrote: > Cool - I was using a JS shim and had asked AWS many times why they couldnât open it up wider... > > Now Iâm back from my travels Iâll reincarnate my previous work and see how it works with this. I was looking forward to doing more with Lambda, so this is great timing. > > Tim > > Sent from my iPhone > >> On 27 Dec 2018, at 10:32, Jan van de Sandt <jvdsandt(a)gmail.com> wrote: >> Hi, >> >> Last month Amazon extended their serverless runtime platform AWS Lambda with support for custom runtimes. I created a Pharo Lambda Runtime so now we can implement Lambda functions in Smalltalk and easily deploy them on the Lambda platform. Lamba has quite a large "free-tier", more than enough to do some experiments and to host small applications for free. >> >> See the GitHub project for more details https://github.com/jvdsandt/pharo-aws-toolbox >> >> Cheers, >> Jan.

Dec. 28, 2018

Re: [Pharo-dev] [Moose-dev] glamorous toolkit: v0.4.0

by Tudor Girba

> On Dec 28, 2018, at 1:08 PM, Kjell Godo <squeaklist(a)gmail.com> wrote: > > WOW :) What part of it do you like? Cheers, Doru > On Thu, Dec 20, 2018 at 01:57 Tudor Girba <tudor(a)tudorgirba.com> wrote: > Hi Luke, > > I am happy this looks exciting :). > > About the confusion part: The Glamorous Toolkit we are working on right now is a complete new world built on a complete new graphical stack that does is not based on the existing stack that ships with Pharo. It is not an evolution. It is a leap. > > The goal of the new GT is to propose a completely reshaped programming experience that enables moldable development. You will find the concepts from the old GT in the new world as well. For example, the Inspector is extensible in similar ways and the API is similar as well. > > But, in the new world, we are bringing the concept much further. For example, Documenter provides a whole new kind of a tool that can mold to unify multiple workflows (like data notebooks, code documentation, or tutorials) right in the IDE. Coder provides the infrastructure for manipulating code that can mold its shape as you type. Transcript allows you to embed various widgets to transform the otherwise dull experience of a console into a live one. > > Behind the scenes GT comes with several engines. The Examples engine enables example-driven development which also bridges the gap between testing and documentation effort, especially when combined with Documenter. Releaser is able to release deeply nested projects. Phlow offers an engine that shares similarities with Glamour. Completer provides moldable completion. Visualizer offers a couple of visualization engines such as Mondrian. > > All of these are possible because of the underlying graphical stack made of Sparta/Bloc/Brick. > > All in all, we believe that the new GT enables a new way of programming. Individual features can be attractive, but our goal is to reshape the development experience. > > Does this address the concern? > > Cheers, > Doru > > > > On Dec 19, 2018, at 2:09 PM, Luke Gorrie <luke(a)snabb.co> wrote: > > > > On Fri, 14 Dec 2018 at 05:13, Tudor Girba <tudor(a)tudorgirba.com> wrote: > > Please do let us know what you think .. and, of course, what you feel. > > > > I'm feeling excited and confused :). > > > > Excited because I love seeing all these new demos streaming out and I'm itching to put new capabilities to work. > > > > Confused about the roadmap. How does this "new" Glamorous Toolkit relate to the "old" one that I learned about last year from the Moldable Tools thesis? Is this a new version or a complete rewrite? Is it backwards compatible or completely reimagined? Is adopting the new version a seamless process or is porting required? Are frameworks like Glamour still there behind the scenes or were they replaced? etc. > > > > > > <gt-documenter-magic-markup.gif><gt-0-4-0.png>_______________________________________________ > > Moose-dev mailing list > > Moose-dev(a)list.inf.unibe.ch > > https://www.list.inf.unibe.ch/listinfo/moose-dev > > -- > www.feenk.com > > "Things happen when they happen, > not when you talk about them happening." > > _______________________________________________ > Moose-dev mailing list > Moose-dev(a)list.inf.unibe.ch > https://www.list.inf.unibe.ch/listinfo/moose-dev > _______________________________________________ > Moose-dev mailing list > Moose-dev(a)list.inf.unibe.ch > https://www.list.inf.unibe.ch/listinfo/moose-dev -- www.feenk.com "Yesterday is a fact. Tomorrow is a possibility. Today is a challenge."

Dec. 28, 2018

Re: [Pharo-dev] [Moose-dev] Re: glamorous toolkit: v0.4.0

by Tudor Girba

Hi, The visualization you describe should be easily doable in the new world. Did you write the visualization in plain Roassal or with the RTMondrian API? Cheers, Doru > On Dec 28, 2018, at 11:32 AM, Luke Gorrie <luke(a)snabb.co> wrote: > > Thanks for the explanations! > > I like the separation between selecting (single-click) and spawning (double-click). The miller column panning is indeed working with a two-finger drag on the touchpad. I will need to test whether this gesture works when running GT on Linux and operating it on a Mac via VNC. That's the most common setup for our application. > > Spotter is not urgent for us. I have written some extensions for it but we aren't really using them much yet. If the inspector is working well then that's the main thing. > > I do have one very important Roassal visualization that I need to bring with me smoothly somehow. Question is whether to port if over to the new framework or somehow smoothly embed Roassal in the new GT? > > The visualization is for compile SSA intermediate representation code and looks like this: > > <Screen Shot 2018-12-28 at 11.25.06.png> > There are some important properties about this diagram: > > - These are two digraphs stacked on top of each other. > - Nodes are always placed below their parents. > - Y-position indicates the max number of edges to reach parent nodes. > - Extra edges (red) can create cycles and should be ignored for layout purposes. > - Nodes can be compound shapes i.e. colored opcode and optionally fused immediate operands in white. > - Each node is an object that can be selected and inspected in the next miller column. > > Can this be done in the new framework with similar effort to the old one? > > On Fri, 28 Dec 2018 at 09:46, Tudor Girba <tudor(a)tudorgirba.com> wrote: > Hi, > > Thanks for the feedback! > > I am happy you like the new possibilities and that you see the incentives to move to the new world :). > > The inspector part is working quite well. The main reason we call it an alpha is because of the missing pieces to get to a full environment. > > You noticed the issue of Spotter. The existing Spotter is the one that is included in the old GT and it lives in the Morphic world. When the focus is in the new inspector, that means that keybindings are handled by Bloc and this is a separate world from Morphic. At present time, we can embed Bloc in Morphic but not the other way around as we want no binding from Bloc to Morphic. For this reason, unhandled keys are not propagated from Bloc to Morphic and that is why pressing Shift+Enter does not open Spotter. > > So, we will have a Spotter, but that will be another implementation. Other unfinished tools are the Debugger and Coder, but these are likely less relevant for your use case. > > A few other missing pieces: > - some widgets such as a tree are not yet implemented. So, we do not yet have a tree view in inspector. > - the text editor requires a few enhancements for navigation support. > - scrollbar > > The Miller-columns interface can be scrolled with the touchpad left-right. Can you confirm? > > About clicking vs double-clicking: Indeed, we now distinguish between selecting and spawning. As soon as there is a page to the right, selecting will populate that page. However, if there is no page to the right, simply selecting in a list will not spawn, like in the old inspector. Like this, you can work on a page without the page scrolling from underneath you. Please note that between pages we have triangles which are actually buttons. Selecting in a list shows a triangle. Clicking on the triangle spawns. So, you can either double-click to spawn, or you can select and then click on the triangle. Once spawned, simple selection is enough. Does this clarify the situation? > > About Roassal: In the new GT we have GtMondrian which is similar to the one from Roassal. We do not yet have support for creating charts (like bar or line charts). > > About the porting strategy: When you have the new GT loaded, the old Inspector will get a _GT pane that will essentially embed the new views in the old inspector. These also allow for interaction. Like this, you can port at your pace and switch only when you are ready. > > Cheers, > Doru > > > > > On Dec 27, 2018, at 11:36 AM, Luke Gorrie <luke(a)snabb.co> wrote: > > > > ... Some comments and questions if I may: > > > > The "+" button to quickly maximize a panel is fantastic. I am often looking at complex visualizations that should really be full-screen and it was always too much trouble to "drag" them to full screen and back. > > > > Is the Spotter still a part of GToolkit? If not then what replaces it? (I can see that it is present in the image but Shift-Return doesn't seem to invoke it when the GTInspector window has focus.) > > > > Is it still possible to pan left-right between "miller columns"? I see the squares at the top representing panes but clicking and dragging them doesn't seem to do anything. > > > > How come a double-click is now needed to inspect an object? Is single-click going to have a new function? > > > > Once more - great work you guys are doing ! > > > > On Thu, 27 Dec 2018 at 11:06, Luke Gorrie <luke(a)snabb.co> wrote: > > Hi Doru, > > > > Thank you very much for the detailed explanation. > > > > I have spent some time with the alpha now. I think it is absolutely fantastic! > > > > I love the new narrative style of the UI. This ties everything together beautifully and makes it easy to explore. That's really what I am lacking in my application. Currently it simply opens to a blank quasi-playground and it is not obvious what to type or how to get started. I started writing a separate HTML manual but I don't think that's the right medium -- much better with something interactive in the image like the Documenter. > > > > Just clicking around everything seemed to work basically smoothly for me. Maybe it's already time for me to port over to the new GT? Or what do you think the most likely obstacles would be in transitioning to this alpha version? > > > > Currently my custom inspector extensions are mostly based on Roassal and List/Tree/Table views. I also have one or two Glamour browsers. Is that all still there in one form or another? > > > > > > _______________________________________________ > > Moose-dev mailing list > > Moose-dev(a)list.inf.unibe.ch > > https://www.list.inf.unibe.ch/listinfo/moose-dev > > -- > www.feenk.com > > "Every thing has its own flow." > > > > > > > _______________________________________________ > Moose-dev mailing list > Moose-dev(a)list.inf.unibe.ch > https://www.list.inf.unibe.ch/listinfo/moose-dev > _______________________________________________ > Moose-dev mailing list > Moose-dev(a)list.inf.unibe.ch > https://www.list.inf.unibe.ch/listinfo/moose-dev -- www.feenk.com "The coherence of a trip is given by the clearness of the goal."

Dec. 28, 2018

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

by Jan van de Sandt

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

Dec. 28, 2018

[Pharo 7.0] Build #84: 22833-PluggableTextMorph-and-co-should-be-removed

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

There is a new Pharo build available! The status of the build #84 was: FAILURE. The Pull Request #2121 was integrated: "22833-PluggableTextMorph-and-co-should-be-removed" Pull request url: https://github.com/pharo-project/pharo/pull/2121 Issue Url: https://pharo.fogbugz.com/f/cases/22833 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Dec. 28, 2018

Re: [Pharo-dev] [Moose-dev] glamorous toolkit: v0.4.0

by Tudor Girba

Hi, Thanks for the feedback! I am happy you like the new possibilities and that you see the incentives to move to the new world :). The inspector part is working quite well. The main reason we call it an alpha is because of the missing pieces to get to a full environment. You noticed the issue of Spotter. The existing Spotter is the one that is included in the old GT and it lives in the Morphic world. When the focus is in the new inspector, that means that keybindings are handled by Bloc and this is a separate world from Morphic. At present time, we can embed Bloc in Morphic but not the other way around as we want no binding from Bloc to Morphic. For this reason, unhandled keys are not propagated from Bloc to Morphic and that is why pressing Shift+Enter does not open Spotter. So, we will have a Spotter, but that will be another implementation. Other unfinished tools are the Debugger and Coder, but these are likely less relevant for your use case. A few other missing pieces: - some widgets such as a tree are not yet implemented. So, we do not yet have a tree view in inspector. - the text editor requires a few enhancements for navigation support. - scrollbar The Miller-columns interface can be scrolled with the touchpad left-right. Can you confirm? About clicking vs double-clicking: Indeed, we now distinguish between selecting and spawning. As soon as there is a page to the right, selecting will populate that page. However, if there is no page to the right, simply selecting in a list will not spawn, like in the old inspector. Like this, you can work on a page without the page scrolling from underneath you. Please note that between pages we have triangles which are actually buttons. Selecting in a list shows a triangle. Clicking on the triangle spawns. So, you can either double-click to spawn, or you can select and then click on the triangle. Once spawned, simple selection is enough. Does this clarify the situation? About Roassal: In the new GT we have GtMondrian which is similar to the one from Roassal. We do not yet have support for creating charts (like bar or line charts). About the porting strategy: When you have the new GT loaded, the old Inspector will get a _GT pane that will essentially embed the new views in the old inspector. These also allow for interaction. Like this, you can port at your pace and switch only when you are ready. Cheers, Doru > On Dec 27, 2018, at 11:36 AM, Luke Gorrie <luke(a)snabb.co> wrote: > > ... Some comments and questions if I may: > > The "+" button to quickly maximize a panel is fantastic. I am often looking at complex visualizations that should really be full-screen and it was always too much trouble to "drag" them to full screen and back. > > Is the Spotter still a part of GToolkit? If not then what replaces it? (I can see that it is present in the image but Shift-Return doesn't seem to invoke it when the GTInspector window has focus.) > > Is it still possible to pan left-right between "miller columns"? I see the squares at the top representing panes but clicking and dragging them doesn't seem to do anything. > > How come a double-click is now needed to inspect an object? Is single-click going to have a new function? > > Once more - great work you guys are doing ! > > On Thu, 27 Dec 2018 at 11:06, Luke Gorrie <luke(a)snabb.co> wrote: > Hi Doru, > > Thank you very much for the detailed explanation. > > I have spent some time with the alpha now. I think it is absolutely fantastic! > > I love the new narrative style of the UI. This ties everything together beautifully and makes it easy to explore. That's really what I am lacking in my application. Currently it simply opens to a blank quasi-playground and it is not obvious what to type or how to get started. I started writing a separate HTML manual but I don't think that's the right medium -- much better with something interactive in the image like the Documenter. > > Just clicking around everything seemed to work basically smoothly for me. Maybe it's already time for me to port over to the new GT? Or what do you think the most likely obstacles would be in transitioning to this alpha version? > > Currently my custom inspector extensions are mostly based on Roassal and List/Tree/Table views. I also have one or two Glamour browsers. Is that all still there in one form or another? > > > _______________________________________________ > Moose-dev mailing list > Moose-dev(a)list.inf.unibe.ch > https://www.list.inf.unibe.ch/listinfo/moose-dev -- www.feenk.com "Every thing has its own flow."

Dec. 28, 2018

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

by Pierce Ng

On Thu, Dec 27, 2018 at 10:32:03AM +0100, Jan van de Sandt wrote: > Last month Amazon extended their serverless runtime platform AWS Lambda > with support for custom runtimes. I created a Pharo Lambda Runtime so now > we can implement Lambda functions in Smalltalk and easily deploy them on > the Lambda platform. Lamba has quite a large "free-tier", more than enough > to do some experiments and to host small applications for free. Very nice! Thanks for making this. Pierce

Dec. 27, 2018

[Pharo 7.0] Build #83: 22841-Fix-printString-related-bugs

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

There is a new Pharo build available! The status of the build #83 was: SUCCESS. The Pull Request #2131 was integrated: "22841-Fix-printString-related-bugs" Pull request url: https://github.com/pharo-project/pharo/pull/2131 Issue Url: https://pharo.fogbugz.com/f/cases/22841 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Dec. 27, 2018

[Pharo 7.0] Build #82: 22826-senders-of-asNonTranslucentColor-should

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

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

Dec. 27, 2018

Re: [Pharo-dev] [ANN] Pharo 8.0 development started

by Torsten Bergmann

and 11. There is no https://get.pharo.org/80 yet ... Bye T.

Dec. 27, 2018

Re: [Pharo-dev] [ANN] Pharo 8.0 development started

by Torsten Bergmann

Hi Esteban, you know I'm neither shy on contributing nor doing any work for Pharo but personally I think we open Pharo 8 too early and should better focus our efforts more on finalizing P7 (see below) instead of opening the next construction site. Things were already shaky and sometimes painful with P7 - nonetheless I managed to get 762 commits into it. Often simple or boring PR's just to get packages, classes, methods in shape and clean up. Funny enough I can now say I'm on top of https://github.com/pharo-project/pharo/graphs/contributors ;) I had a hard time finding out how things work in the new git/pharo/externally managed projects combination - sometimes also with broken or unfinished tools. A newly opened P8 so early adds even more on top... Several things directly came into my mind: 1. http://bugs.pharo.org now points to nirvana now 2. http://ci.pharo.org point to nirvana now as well 3. It's unclear to me what will happen to the bugtracker mailinglist archive. Currently I often use it to stay informed about our changes. Will it stop in december? https://lists.gforge.inria.fr/pipermail/pharo-bugtracker/ 4. The CI for Pharo 7 was not green in most of the latest commits ... and situation for Pharo 8 is not even better now: RED all over on https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2… 5. We still have dirty packages in Pharo 7 - the last remaining issue here https://github.com/pharo-ide/Calypso/issues/386 is still not solved and there was no reaction on Discord after reminding it twice. 6. Calypso still has hard issue in Pharo 7 - most of them already fixed in Calypso project. But integration of the new Calypso version is still pending https://github.com/pharo-project/pharo/pull/2115 Nonetheless we already switch to P8? 7. A change done lately (around 17.12.) was resetting the build numbers - so for whatever strange reason we started with 1 again althoug we were already at Build 1416 for Pharo 7 with all the integrations. https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2… This build number issue was not yet fixed although this is a serious issue to compare image buils or be able to download using Launcher. Nonetheless we already switch to P8? 8. Lately we switched the branches from "development" to "Pharo7.0" and now also "Pharo8.0". This was also just announced - without any discussion in advance forcing people to resetup their tools and local repos. This change is still not event reflected in the contribution guideline ... but we already switch to Pharo 8 9. We still have lots of important and must-fix cases for Pharo 7 https://pharo.fogbugz.com/f/filters/1412/7-0-All 10. There was nothing said about backporting strategy between the new P8 and P7 now... To me it would already help a little bit to clarify the above raised points and get a more detailed info about the next P7 steps towards the release. Independent from that I fear we constantly decouple more and more people with too many process and contribution scheme changes at once. From the discussions on Discord I already see many people struggle - and often not only the beginners. Bye T.

Dec. 27, 2018

Re: [Pharo-dev] [ANN] Pharo 8.0 development started

by Alistair Grant

Hi Esteban, On Thu, 27 Dec 2018 at 15:52, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > > Hi Alistair, > > Iâm waiting to fix some issues in current VM build (new freetype lib, ensure Athens will work on 64bit windows) and I was going to declare that âfinal vm for Pharo7â. > Then this final VM for P7 will be the first for P8 :) Great, that will include the updates that I'm waiting for: updates to FileAttributesPlugin. I'll then be able to (finally) submit the patch for the image code. Thanks! Alistair > Esteban > > > On 27 Dec 2018, at 15:11, Alistair Grant <akgrant0710(a)gmail.com> wrote: > > > > Hi Esteban, > > > > Can I get in an early request for a new VM for Pharo 8? > > > > Since the normal process is to ensure the VM is at least 2 weeks old > > it doesn't require any action now, and of course it can wait until > > Pharo 7 is released. > > > > - Linux 64 bit: > > http://files.pharo.org/vm/pharo-spur64/linux/pharo-linux-x86_64threaded-201… > > - Mac 64 bit: http://files.pharo.org/vm/pharo-spur64/mac/pharo-mac-x86_64-201812211409-10… > > - Win 32 bit: http://files.pharo.org/vm/pharo-spur32/win/pharo-win-i386-201812211809-e14d… > > > > Thanks! > > > > Alistair > > > > On Thu, 27 Dec 2018 at 09:51, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > >> > >> Hello all, > >> > >> We are preparing to release Pharo 7.0 (which will be in January, as soon as we finish some last details). And in the meantime impatient people has asked (and obtained) the aperture of Pharo 8.0 development! :) > >> > >> So you now can start making Pull Requests against Pharo8.0 branch :) > >> > >> Esteban > > > >

Dec. 27, 2018

Re: [Pharo-dev] [ANN] Pharo 8.0 development started

by Esteban Lorenzano

Hi Alistair, Iâm waiting to fix some issues in current VM build (new freetype lib, ensure Athens will work on 64bit windows) and I was going to declare that âfinal vm for Pharo7â. Then this final VM for P7 will be the first for P8 :) Esteban > On 27 Dec 2018, at 15:11, Alistair Grant <akgrant0710(a)gmail.com> wrote: > > Hi Esteban, > > Can I get in an early request for a new VM for Pharo 8? > > Since the normal process is to ensure the VM is at least 2 weeks old > it doesn't require any action now, and of course it can wait until > Pharo 7 is released. > > - Linux 64 bit: > http://files.pharo.org/vm/pharo-spur64/linux/pharo-linux-x86_64threaded-201… > - Mac 64 bit: http://files.pharo.org/vm/pharo-spur64/mac/pharo-mac-x86_64-201812211409-10… > - Win 32 bit: http://files.pharo.org/vm/pharo-spur32/win/pharo-win-i386-201812211809-e14d… > > Thanks! > > Alistair > > On Thu, 27 Dec 2018 at 09:51, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: >> >> Hello all, >> >> We are preparing to release Pharo 7.0 (which will be in January, as soon as we finish some last details). And in the meantime impatient people has asked (and obtained) the aperture of Pharo 8.0 development! :) >> >> So you now can start making Pull Requests against Pharo8.0 branch :) >> >> Esteban >

Dec. 27, 2018

Re: [Pharo-dev] [ANN] Pharo 8.0 development started

by Alistair Grant

Hi Esteban, Can I get in an early request for a new VM for Pharo 8? Since the normal process is to ensure the VM is at least 2 weeks old it doesn't require any action now, and of course it can wait until Pharo 7 is released. - Linux 64 bit: http://files.pharo.org/vm/pharo-spur64/linux/pharo-linux-x86_64threaded-201… - Mac 64 bit: http://files.pharo.org/vm/pharo-spur64/mac/pharo-mac-x86_64-201812211409-10… - Win 32 bit: http://files.pharo.org/vm/pharo-spur32/win/pharo-win-i386-201812211809-e14d… Thanks! Alistair On Thu, 27 Dec 2018 at 09:51, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > > Hello all, > > We are preparing to release Pharo 7.0 (which will be in January, as soon as we finish some last details). And in the meantime impatient people has asked (and obtained) the aperture of Pharo 8.0 development! :) > > So you now can start making Pull Requests against Pharo8.0 branch :) > > Esteban

Dec. 27, 2018

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

by Tim Mackinnon

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

Dec. 27, 2018

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

by Sven Van Caekenberghe

Nice job. Well documented. Thank you. > On 27 Dec 2018, at 10:32, Jan van de Sandt <jvdsandt(a)gmail.com> wrote: > > Hi, > > Last month Amazon extended their serverless runtime platform AWS Lambda with support for custom runtimes. I created a Pharo Lambda Runtime so now we can implement Lambda functions in Smalltalk and easily deploy them on the Lambda platform. Lamba has quite a large "free-tier", more than enough to do some experiments and to host small applications for free. > > See the GitHub project for more details https://github.com/jvdsandt/pharo-aws-toolbox > > Cheers, > Jan.

Dec. 27, 2018

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

by Ben Coman

This sounds really great. Something I'd like to experiment with. Thanks. cheers -ben On Thu, 27 Dec 2018 at 17:32, Jan van de Sandt <jvdsandt(a)gmail.com> wrote: > Hi, > > Last month Amazon extended their serverless runtime platform AWS Lambda > with support for custom runtimes. I created a Pharo Lambda Runtime so now > we can implement Lambda functions in Smalltalk and easily deploy them on > the Lambda platform. Lamba has quite a large "free-tier", more than enough > to do some experiments and to host small applications for free. > > See the GitHub project for more details > https://github.com/jvdsandt/pharo-aws-toolbox > > Cheers, > Jan. >

Dec. 27, 2018

Re: [Pharo-dev] [ANN][IMPORTANT] Pharo 8.0 issue tracker is MOVED to GitHub

by Ben Coman

On Thu, 27 Dec 2018 at 17:04, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > Hi, > > As part of our constant try to enhance process, we are moving the issue > tracker to GitHub. > You can now declare issues here: > > https://github.com/pharo-project/pharo/issues > > FAQ: > > Q: Why we do this? > A: > - Because reuniting all development process in just one point will enhance > traceability > - â¦ and communication (there are a lot of conversations that now happens > in different places (list, issue, PR). With this move we put issue and PR > discussion in same place. > - â¦ and people historically has complained that âthey need to log to > fogbugz to just see the issuesâ > - â¦ and this allows us to decommission one server we have now just to get > the issues names when creating branches (and before slides). > > Q: Does that means fogbugz is bad? > A: Not at all! It is a great tool and we are very grateful of it. Is just > that we want to reunite our communication into a single point. > > Q: What will happen with issues reported in FogBugz? > A: Pharo 7.0 issues will be taken as before. Pharo 8.0 issues need to be > re-opened in GitHub. There are less than 25 right now and we ask people > reporting it to move them again (maybe we would do it, but better is owners > do). > That all sounds fair and reasonable. I just want to clarify if there was going to be any issue migration of old/closed issues (after Pharo 7 release). I understand its a big effort and the value might not be worth it - but just curious what are the constraints and plans. cheers -ben

Dec. 27, 2018

[Pharo 7.0] Build #81: 22802-ZipArchive-should-throw-specific-Error

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

There is a new Pharo build available! The status of the build #81 was: FAILURE. The Pull Request #2119 was integrated: "22802-ZipArchive-should-throw-specific-Error" Pull request url: https://github.com/pharo-project/pharo/pull/2119 Issue Url: https://pharo.fogbugz.com/f/cases/22802 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Dec. 27, 2018

[Pharo 8.0] Build #2: Removed obsolete Fuel package

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

There is a new Pharo build available! The status of the build #2 was: FAILURE. The Pull Request #2122 was integrated: "Removed obsolete Fuel package" Pull request url: https://github.com/pharo-project/pharo/pull/2122 Issue Url: https://pharo.fogbugz.com/f/cases/22834 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Dec. 27, 2018

[Pharo 7.0] Build #80: SUCCESS

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

There is a new Pharo build available! The status of the build #80 was: SUCCESS. Could not extract further issue information from commit message: references to fogbugz moved to GitHub tracker Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Dec. 27, 2018

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

by Guillermo Polito

Cool! thanks! On Thu, Dec 27, 2018 at 10:32 AM Jan van de Sandt <jvdsandt(a)gmail.com> wrote: > Hi, > > Last month Amazon extended their serverless runtime platform AWS Lambda > with support for custom runtimes. I created a Pharo Lambda Runtime so now > we can implement Lambda functions in Smalltalk and easily deploy them on > the Lambda platform. Lamba has quite a large "free-tier", more than enough > to do some experiments and to host small applications for free. > > See the GitHub project for more details > https://github.com/jvdsandt/pharo-aws-toolbox > > Cheers, > Jan. > -- 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

Dec. 27, 2018

[ANN] Pharo Lambda Runtime

by Jan van de Sandt

Hi, Last month Amazon extended their serverless runtime platform AWS Lambda with support for custom runtimes. I created a Pharo Lambda Runtime so now we can implement Lambda functions in Smalltalk and easily deploy them on the Lambda platform. Lamba has quite a large "free-tier", more than enough to do some experiments and to host small applications for free. See the GitHub project for more details https://github.com/jvdsandt/pharo-aws-toolbox Cheers, Jan.

Dec. 27, 2018

[ANN][IMPORTANT] Pharo 8.0 issue tracker is MOVED to GitHub

by Esteban Lorenzano

Hi, As part of our constant try to enhance process, we are moving the issue tracker to GitHub. You can now declare issues here: https://github.com/pharo-project/pharo/issues <https://github.com/pharo-project/pharo/issues> FAQ: Q: Why we do this? A: - Because reuniting all development process in just one point will enhance traceability - â¦ and communication (there are a lot of conversations that now happens in different places (list, issue, PR). With this move we put issue and PR discussion in same place. - â¦ and people historically has complained that âthey need to log to fogbugz to just see the issuesâ - â¦ and this allows us to decommission one server we have now just to get the issues names when creating branches (and before slides). Q: Does that means fogbugz is bad? A: Not at all! It is a great tool and we are very grateful of it. Is just that we want to reunite our communication into a single point. Q: What will happen with issues reported in FogBugz? A: Pharo 7.0 issues will be taken as before. Pharo 8.0 issues need to be re-opened in GitHub. There are less than 25 right now and we ask people reporting it to move them again (maybe we would do it, but better is owners do). Q: How can we âbranch from issueâ now if we do not have FogBugz? A: We already added a tool âbranch from issueâ that uses GitHub issue tracker. This will be the same as before. And for the same price, we add that option to other projects: All GitHub projects now can benefit from âbranch from issueâ functionality. Cheers! Esteban

Dec. 27, 2018

[ANN] Pharo 8.0 development started

by Esteban Lorenzano

Hello all, We are preparing to release Pharo 7.0 (which will be in January, as soon as we finish some last details). And in the meantime impatient people has asked (and obtained) the aperture of Pharo 8.0 development! :) So you now can start making Pull Requests against Pharo8.0 branch :) Esteban

Dec. 27, 2018

Re: [Pharo-dev] Pharo 7 changelog proposal

by Guillermo Polito

Cool list, thanks Pavel ^^. On Sun, Dec 23, 2018 at 12:29 PM Pavel Krivanek <pavel.krivanek(a)gmail.com> wrote: > Hi, > > I'm trying to summarize the changelog for Pharo 7 (based on about 2500 > merged PRs, not counting standalone commits to Iceberg and Calypso). If > something more should be mentioned, please let me know. > > Revolutionary kernel changes > - bootstrap > - modular stateful traits > - traits flattening in kernel packages > - new sources file for every bootstrapped version, empty changes > - new class builder > - binary packages loading (Hermes) > > Infrastructure changes > - switch to GitHub > - Tonel code format > - update building infrastructure to Jenkins 2 > > Code management > - Calypso, the new system browser > - new navigation model > - faster UI > - tabs toolbar instead of single source code panel > - explicit commands instead of duplicated menu and shortcuts > - extendable by plugins > - suitable for the remote scenario > - "dynamic protocols", support multiple tags per method > - not required star convention for class extension > - support multiple tags per class > - visibility option for inherited methods > - methods inherited from traits are not shown by default > - variable view as the special mode for method group view. > - better keyboard navigation > - and many more > > Iceberg > - a new friendly user interface > - simplification of solving problems with repositories > - workflow simplification > - better GitHub, BitBucket, GitLab support > - improved code merging and comparisons > - new code serialization format (Tonel) > - repositories metadata > - documentation > - better error handling, tags support > - improved Iceberg-Metacello integration > - credentials store > > Cleanups > - remove Nautilus > - remove UpdateStream > - remove all Configurations > - remove ShoreLine-Report > - remove TxText > - remove PluggableTabBarMorph > - remove the old Compiler > - remove Watery theme > - remove Versionner > - remove Komitter > - remove LegacyWeakSubscription > - continue on deprecation of FileStream > - dead code cleanups > - code organization cleanups > - unify categorization of common methods > - cleanups of object inspection protocol > - start with Ring deprecation > - better structure of packages > - package comments > > Updates > - Zinc > - Epicea > - FFI > - Metacello > - Fuel > > New > - Calypso > - integrate WebBrowser > - integrate ReferenceFinder > - Hermes > - Refactoring 2 > - Commander > - ClassAnnotation > > Spec > - ComposableModel renamed to ComposablePresenter > - new calendar presenter > - Spec-Demo > - improve Spec linking to domain models > > Look & Feel > - use the white theme by default > - improve themes switching > - main menu bar > - new window management shortcuts > - better support of fallback bitmap fonts > - improved Inspector refreshing > - Spotter is looking for opened windows > - display scale factor > - FastTable improvements > > VM interface > - DoubleWord and DoubleByte arrays > - add EncoderForSistaV1 > - read-only literals support > - improvements and fixes for 64-bit support > - fixes for FullBlockClosure > - support of the new bytecode set > > Reflectivity > - breakpoints improvements > - test coverage using metalinks > - reflectivity and metalinks improvements > > Other > - startup running in a fresh process > - better pin messages > - NewValueHolder and Model API unification > - better working and image directories meaning separation > - SortFunctions composable > - better OSWindow support > - convert rules to the Renraku architecture > - class and method comments improvements > - extensible Playground (pageActionOrder:) > - optional password management for command line handlers > - system dependencies tests > - unify way to obtain package manifests > -- 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

Dec. 26, 2018

Re: [Pharo-dev] Pharo 7 changelog proposal

by Stephane Ducasse

The logic of the Finder was totally rewritten and it is now A LOT better. The previous version was a really inheritance from another age :). Thanks Yoan Geran for his really superb dedication to this task. Stef On Sun, Dec 23, 2018 at 12:29 PM Pavel Krivanek <pavel.krivanek(a)gmail.com> wrote: > > Hi, > > I'm trying to summarize the changelog for Pharo 7 (based on about 2500 merged PRs, not counting standalone commits to Iceberg and Calypso). If something more should be mentioned, please let me know. > > Revolutionary kernel changes > - bootstrap > - modular stateful traits > - traits flattening in kernel packages > - new sources file for every bootstrapped version, empty changes > - new class builder > - binary packages loading (Hermes) > > Infrastructure changes > - switch to GitHub > - Tonel code format > - update building infrastructure to Jenkins 2 > > Code management > - Calypso, the new system browser > - new navigation model > - faster UI > - tabs toolbar instead of single source code panel > - explicit commands instead of duplicated menu and shortcuts > - extendable by plugins > - suitable for the remote scenario > - "dynamic protocols", support multiple tags per method > - not required star convention for class extension > - support multiple tags per class > - visibility option for inherited methods > - methods inherited from traits are not shown by default > - variable view as the special mode for method group view. > - better keyboard navigation > - and many more > > Iceberg > - a new friendly user interface > - simplification of solving problems with repositories > - workflow simplification > - better GitHub, BitBucket, GitLab support > - improved code merging and comparisons > - new code serialization format (Tonel) > - repositories metadata > - documentation > - better error handling, tags support > - improved Iceberg-Metacello integration > - credentials store > > Cleanups > - remove Nautilus > - remove UpdateStream > - remove all Configurations > - remove ShoreLine-Report > - remove TxText > - remove PluggableTabBarMorph > - remove the old Compiler > - remove Watery theme > - remove Versionner > - remove Komitter > - remove LegacyWeakSubscription > - continue on deprecation of FileStream > - dead code cleanups > - code organization cleanups > - unify categorization of common methods > - cleanups of object inspection protocol > - start with Ring deprecation > - better structure of packages > - package comments > > Updates > - Zinc > - Epicea > - FFI > - Metacello > - Fuel > > New > - Calypso > - integrate WebBrowser > - integrate ReferenceFinder > - Hermes > - Refactoring 2 > - Commander > - ClassAnnotation > > Spec > - ComposableModel renamed to ComposablePresenter > - new calendar presenter > - Spec-Demo > - improve Spec linking to domain models > > Look & Feel > - use the white theme by default > - improve themes switching > - main menu bar > - new window management shortcuts > - better support of fallback bitmap fonts > - improved Inspector refreshing > - Spotter is looking for opened windows > - display scale factor > - FastTable improvements > > VM interface > - DoubleWord and DoubleByte arrays > - add EncoderForSistaV1 > - read-only literals support > - improvements and fixes for 64-bit support > - fixes for FullBlockClosure > - support of the new bytecode set > > Reflectivity > - breakpoints improvements > - test coverage using metalinks > - reflectivity and metalinks improvements > > Other > - startup running in a fresh process > - better pin messages > - NewValueHolder and Model API unification > - better working and image directories meaning separation > - SortFunctions composable > - better OSWindow support > - convert rules to the Renraku architecture > - class and method comments improvements > - extensible Playground (pageActionOrder:) > - optional password management for command line handlers > - system dependencies tests > - unify way to obtain package manifests

Dec. 25, 2018

Re: [Pharo-dev] Pharo 7 changelog proposal

by Stephane Ducasse

Thanks pavel. This is indeed a really nice list. Thanks for your effort to gather this summary. BTW: I would put a bit more emphasis on the new stream and deprecation of the old stream hierarchy because it was a large effort. And I want to thank guillermo for this. Stef On Sun, Dec 23, 2018 at 12:29 PM Pavel Krivanek <pavel.krivanek(a)gmail.com> wrote: > > Hi, > > I'm trying to summarize the changelog for Pharo 7 (based on about 2500 merged PRs, not counting standalone commits to Iceberg and Calypso). If something more should be mentioned, please let me know. > > Revolutionary kernel changes > - bootstrap > - modular stateful traits > - traits flattening in kernel packages > - new sources file for every bootstrapped version, empty changes > - new class builder > - binary packages loading (Hermes) > > Infrastructure changes > - switch to GitHub > - Tonel code format > - update building infrastructure to Jenkins 2 > > Code management > - Calypso, the new system browser > - new navigation model > - faster UI > - tabs toolbar instead of single source code panel > - explicit commands instead of duplicated menu and shortcuts > - extendable by plugins > - suitable for the remote scenario > - "dynamic protocols", support multiple tags per method > - not required star convention for class extension > - support multiple tags per class > - visibility option for inherited methods > - methods inherited from traits are not shown by default > - variable view as the special mode for method group view. > - better keyboard navigation > - and many more > > Iceberg > - a new friendly user interface > - simplification of solving problems with repositories > - workflow simplification > - better GitHub, BitBucket, GitLab support > - improved code merging and comparisons > - new code serialization format (Tonel) > - repositories metadata > - documentation > - better error handling, tags support > - improved Iceberg-Metacello integration > - credentials store > > Cleanups > - remove Nautilus > - remove UpdateStream > - remove all Configurations > - remove ShoreLine-Report > - remove TxText > - remove PluggableTabBarMorph > - remove the old Compiler > - remove Watery theme > - remove Versionner > - remove Komitter > - remove LegacyWeakSubscription > - continue on deprecation of FileStream > - dead code cleanups > - code organization cleanups > - unify categorization of common methods > - cleanups of object inspection protocol > - start with Ring deprecation > - better structure of packages > - package comments > > Updates > - Zinc > - Epicea > - FFI > - Metacello > - Fuel > > New > - Calypso > - integrate WebBrowser > - integrate ReferenceFinder > - Hermes > - Refactoring 2 > - Commander > - ClassAnnotation > > Spec > - ComposableModel renamed to ComposablePresenter > - new calendar presenter > - Spec-Demo > - improve Spec linking to domain models > > Look & Feel > - use the white theme by default > - improve themes switching > - main menu bar > - new window management shortcuts > - better support of fallback bitmap fonts > - improved Inspector refreshing > - Spotter is looking for opened windows > - display scale factor > - FastTable improvements > > VM interface > - DoubleWord and DoubleByte arrays > - add EncoderForSistaV1 > - read-only literals support > - improvements and fixes for 64-bit support > - fixes for FullBlockClosure > - support of the new bytecode set > > Reflectivity > - breakpoints improvements > - test coverage using metalinks > - reflectivity and metalinks improvements > > Other > - startup running in a fresh process > - better pin messages > - NewValueHolder and Model API unification > - better working and image directories meaning separation > - SortFunctions composable > - better OSWindow support > - convert rules to the Renraku architecture > - class and method comments improvements > - extensible Playground (pageActionOrder:) > - optional password management for command line handlers > - system dependencies tests > - unify way to obtain package manifests

Dec. 25, 2018

Re: [Pharo-dev] Downloading file with Zinc

by Sven Van Caekenberghe

> On 21 Dec 2018, at 21:55, Stephane Ducasse <stepharo.self(a)gmail.com> wrote: > > Tx > This is strange since I looked for download and the system did not > show it to me. > > Stef Open Spotter, type 'download', click implementors, look at the end or filter on 'Zn'. The #saveContentsToFile: is used in snippet number 18 of Elegant Pharo Code, https://medium.com/concerning-pharo/elegant-pharo-code-bb590f0856d0 (already from 2014). > On Fri, Dec 21, 2018 at 9:55 AM Sven Van Caekenberghe <sven(a)stfx.eu> wrote: >> >> >> >>> On 21 Dec 2018, at 05:25, Jimmie Houchin <jlhouchin(a)gmail.com> wrote: >>> >>> On 12/20/18 1:59 PM, Stephane Ducasse wrote: >>>> Hi Sven >>>> >>>> I would like download files (pdf) with Zinc (not opening them in Pharo). >>>> I wonder how I can do it with zinc. >>>> >>>> Tx >>> >>> 'http://files.pharo.org/books-pdfs/learning-oop/2018-04-01-LearningOOP.pdf' asZnUrl saveContentsToFile: '/mypath/mydir/learning-oop.pdf' >>> >>> Should get you going. >>> >>> Jimmie >> >> There is also ZnClient>>#downloadTo: >> >> ZnClient new url: ''; downloadTo: ''. >> >> Read the comment >> >> >

Dec. 23, 2018

Re: [Pharo-dev] Pharo 7 changelog proposal

by Sven Van Caekenberghe

> On 23 Dec 2018, at 20:01, Pavel Krivanek <pavel.krivanek(a)gmail.com> wrote: > > Hi Alistair, > > the FileStream is supposed to be deprecated for several releases. In Pharo 7, we just take it more seriously. We should link to the related deprecation guides. The changelog already contains: "continue on deprecation of FileStream". Moreover, we will add a list of all deprecated methods and classes as we did for Pharo 6. The difference is that a couple of classes actually moved to Deprecated and using them now results in warnings. And although there are still reference to the Deprecated classes, I am relatively sure that the bulk of file stream usage now goes via the newer classes. This is an important milestone and change. >From now on, the message is: use FileReferences and ask them for the [read|write] [character|binary] streams that you need, and what you get back will be different but mostly compatible, the non-compatible changes are deliberate design choices. > -- Pavel > > ne 23. 12. 2018 v 18:23 odesÃlatel Alistair Grant <akgrant0710(a)gmail.com> napsal: > Hi Pavel, > > You've mentioned the Zinc update and deprecating FileStream, but I > think the adoption of Zinc streams as the default is probably worth > it's own entry (that was Pharo 7, right?, maybe my memory is failing). > > Cheers, > Alistair > > On Sun, 23 Dec 2018 at 12:29, Pavel Krivanek <pavel.krivanek(a)gmail.com> wrote: > > > > Hi, > > > > I'm trying to summarize the changelog for Pharo 7 (based on about 2500 merged PRs, not counting standalone commits to Iceberg and Calypso). If something more should be mentioned, please let me know. > > > > Revolutionary kernel changes > > - bootstrap > > - modular stateful traits > > - traits flattening in kernel packages > > - new sources file for every bootstrapped version, empty changes > > - new class builder > > - binary packages loading (Hermes) > > > > Infrastructure changes > > - switch to GitHub > > - Tonel code format > > - update building infrastructure to Jenkins 2 > > > > Code management > > - Calypso, the new system browser > > - new navigation model > > - faster UI > > - tabs toolbar instead of single source code panel > > - explicit commands instead of duplicated menu and shortcuts > > - extendable by plugins > > - suitable for the remote scenario > > - "dynamic protocols", support multiple tags per method > > - not required star convention for class extension > > - support multiple tags per class > > - visibility option for inherited methods > > - methods inherited from traits are not shown by default > > - variable view as the special mode for method group view. > > - better keyboard navigation > > - and many more > > > > Iceberg > > - a new friendly user interface > > - simplification of solving problems with repositories > > - workflow simplification > > - better GitHub, BitBucket, GitLab support > > - improved code merging and comparisons > > - new code serialization format (Tonel) > > - repositories metadata > > - documentation > > - better error handling, tags support > > - improved Iceberg-Metacello integration > > - credentials store > > > > Cleanups > > - remove Nautilus > > - remove UpdateStream > > - remove all Configurations > > - remove ShoreLine-Report > > - remove TxText > > - remove PluggableTabBarMorph > > - remove the old Compiler > > - remove Watery theme > > - remove Versionner > > - remove Komitter > > - remove LegacyWeakSubscription > > - continue on deprecation of FileStream > > - dead code cleanups > > - code organization cleanups > > - unify categorization of common methods > > - cleanups of object inspection protocol > > - start with Ring deprecation > > - better structure of packages > > - package comments > > > > Updates > > - Zinc > > - Epicea > > - FFI > > - Metacello > > - Fuel > > > > New > > - Calypso > > - integrate WebBrowser > > - integrate ReferenceFinder > > - Hermes > > - Refactoring 2 > > - Commander > > - ClassAnnotation > > > > Spec > > - ComposableModel renamed to ComposablePresenter > > - new calendar presenter > > - Spec-Demo > > - improve Spec linking to domain models > > > > Look & Feel > > - use the white theme by default > > - improve themes switching > > - main menu bar > > - new window management shortcuts > > - better support of fallback bitmap fonts > > - improved Inspector refreshing > > - Spotter is looking for opened windows > > - display scale factor > > - FastTable improvements > > > > VM interface > > - DoubleWord and DoubleByte arrays > > - add EncoderForSistaV1 > > - read-only literals support > > - improvements and fixes for 64-bit support > > - fixes for FullBlockClosure > > - support of the new bytecode set > > > > Reflectivity > > - breakpoints improvements > > - test coverage using metalinks > > - reflectivity and metalinks improvements > > > > Other > > - startup running in a fresh process > > - better pin messages > > - NewValueHolder and Model API unification > > - better working and image directories meaning separation > > - SortFunctions composable > > - better OSWindow support > > - convert rules to the Renraku architecture > > - class and method comments improvements > > - extensible Playground (pageActionOrder:) > > - optional password management for command line handlers > > - system dependencies tests > > - unify way to obtain package manifests >

Dec. 23, 2018

Re: [Pharo-dev] Pharo 7 changelog proposal

by Pavel Krivanek

Hi Alistair, the FileStream is supposed to be deprecated for several releases. In Pharo 7, we just take it more seriously. We should link to the related deprecation guides. The changelog already contains: "continue on deprecation of FileStream". Moreover, we will add a list of all deprecated methods and classes as we did for Pharo 6. -- Pavel ne 23. 12. 2018 v 18:23 odesÃlatel Alistair Grant <akgrant0710(a)gmail.com> napsal: > Hi Pavel, > > You've mentioned the Zinc update and deprecating FileStream, but I > think the adoption of Zinc streams as the default is probably worth > it's own entry (that was Pharo 7, right?, maybe my memory is failing). > > Cheers, > Alistair > > On Sun, 23 Dec 2018 at 12:29, Pavel Krivanek <pavel.krivanek(a)gmail.com> > wrote: > > > > Hi, > > > > I'm trying to summarize the changelog for Pharo 7 (based on about 2500 > merged PRs, not counting standalone commits to Iceberg and Calypso). If > something more should be mentioned, please let me know. > > > > Revolutionary kernel changes > > - bootstrap > > - modular stateful traits > > - traits flattening in kernel packages > > - new sources file for every bootstrapped version, empty changes > > - new class builder > > - binary packages loading (Hermes) > > > > Infrastructure changes > > - switch to GitHub > > - Tonel code format > > - update building infrastructure to Jenkins 2 > > > > Code management > > - Calypso, the new system browser > > - new navigation model > > - faster UI > > - tabs toolbar instead of single source code panel > > - explicit commands instead of duplicated menu and shortcuts > > - extendable by plugins > > - suitable for the remote scenario > > - "dynamic protocols", support multiple tags per method > > - not required star convention for class extension > > - support multiple tags per class > > - visibility option for inherited methods > > - methods inherited from traits are not shown by default > > - variable view as the special mode for method group view. > > - better keyboard navigation > > - and many more > > > > Iceberg > > - a new friendly user interface > > - simplification of solving problems with repositories > > - workflow simplification > > - better GitHub, BitBucket, GitLab support > > - improved code merging and comparisons > > - new code serialization format (Tonel) > > - repositories metadata > > - documentation > > - better error handling, tags support > > - improved Iceberg-Metacello integration > > - credentials store > > > > Cleanups > > - remove Nautilus > > - remove UpdateStream > > - remove all Configurations > > - remove ShoreLine-Report > > - remove TxText > > - remove PluggableTabBarMorph > > - remove the old Compiler > > - remove Watery theme > > - remove Versionner > > - remove Komitter > > - remove LegacyWeakSubscription > > - continue on deprecation of FileStream > > - dead code cleanups > > - code organization cleanups > > - unify categorization of common methods > > - cleanups of object inspection protocol > > - start with Ring deprecation > > - better structure of packages > > - package comments > > > > Updates > > - Zinc > > - Epicea > > - FFI > > - Metacello > > - Fuel > > > > New > > - Calypso > > - integrate WebBrowser > > - integrate ReferenceFinder > > - Hermes > > - Refactoring 2 > > - Commander > > - ClassAnnotation > > > > Spec > > - ComposableModel renamed to ComposablePresenter > > - new calendar presenter > > - Spec-Demo > > - improve Spec linking to domain models > > > > Look & Feel > > - use the white theme by default > > - improve themes switching > > - main menu bar > > - new window management shortcuts > > - better support of fallback bitmap fonts > > - improved Inspector refreshing > > - Spotter is looking for opened windows > > - display scale factor > > - FastTable improvements > > > > VM interface > > - DoubleWord and DoubleByte arrays > > - add EncoderForSistaV1 > > - read-only literals support > > - improvements and fixes for 64-bit support > > - fixes for FullBlockClosure > > - support of the new bytecode set > > > > Reflectivity > > - breakpoints improvements > > - test coverage using metalinks > > - reflectivity and metalinks improvements > > > > Other > > - startup running in a fresh process > > - better pin messages > > - NewValueHolder and Model API unification > > - better working and image directories meaning separation > > - SortFunctions composable > > - better OSWindow support > > - convert rules to the Renraku architecture > > - class and method comments improvements > > - extensible Playground (pageActionOrder:) > > - optional password management for command line handlers > > - system dependencies tests > > - unify way to obtain package manifests > >

Dec. 23, 2018

Re: [Pharo-dev] Pharo 7 changelog proposal

by Alistair Grant

Hi Pavel, You've mentioned the Zinc update and deprecating FileStream, but I think the adoption of Zinc streams as the default is probably worth it's own entry (that was Pharo 7, right?, maybe my memory is failing). Cheers, Alistair On Sun, 23 Dec 2018 at 12:29, Pavel Krivanek <pavel.krivanek(a)gmail.com> wrote: > > Hi, > > I'm trying to summarize the changelog for Pharo 7 (based on about 2500 merged PRs, not counting standalone commits to Iceberg and Calypso). If something more should be mentioned, please let me know. > > Revolutionary kernel changes > - bootstrap > - modular stateful traits > - traits flattening in kernel packages > - new sources file for every bootstrapped version, empty changes > - new class builder > - binary packages loading (Hermes) > > Infrastructure changes > - switch to GitHub > - Tonel code format > - update building infrastructure to Jenkins 2 > > Code management > - Calypso, the new system browser > - new navigation model > - faster UI > - tabs toolbar instead of single source code panel > - explicit commands instead of duplicated menu and shortcuts > - extendable by plugins > - suitable for the remote scenario > - "dynamic protocols", support multiple tags per method > - not required star convention for class extension > - support multiple tags per class > - visibility option for inherited methods > - methods inherited from traits are not shown by default > - variable view as the special mode for method group view. > - better keyboard navigation > - and many more > > Iceberg > - a new friendly user interface > - simplification of solving problems with repositories > - workflow simplification > - better GitHub, BitBucket, GitLab support > - improved code merging and comparisons > - new code serialization format (Tonel) > - repositories metadata > - documentation > - better error handling, tags support > - improved Iceberg-Metacello integration > - credentials store > > Cleanups > - remove Nautilus > - remove UpdateStream > - remove all Configurations > - remove ShoreLine-Report > - remove TxText > - remove PluggableTabBarMorph > - remove the old Compiler > - remove Watery theme > - remove Versionner > - remove Komitter > - remove LegacyWeakSubscription > - continue on deprecation of FileStream > - dead code cleanups > - code organization cleanups > - unify categorization of common methods > - cleanups of object inspection protocol > - start with Ring deprecation > - better structure of packages > - package comments > > Updates > - Zinc > - Epicea > - FFI > - Metacello > - Fuel > > New > - Calypso > - integrate WebBrowser > - integrate ReferenceFinder > - Hermes > - Refactoring 2 > - Commander > - ClassAnnotation > > Spec > - ComposableModel renamed to ComposablePresenter > - new calendar presenter > - Spec-Demo > - improve Spec linking to domain models > > Look & Feel > - use the white theme by default > - improve themes switching > - main menu bar > - new window management shortcuts > - better support of fallback bitmap fonts > - improved Inspector refreshing > - Spotter is looking for opened windows > - display scale factor > - FastTable improvements > > VM interface > - DoubleWord and DoubleByte arrays > - add EncoderForSistaV1 > - read-only literals support > - improvements and fixes for 64-bit support > - fixes for FullBlockClosure > - support of the new bytecode set > > Reflectivity > - breakpoints improvements > - test coverage using metalinks > - reflectivity and metalinks improvements > > Other > - startup running in a fresh process > - better pin messages > - NewValueHolder and Model API unification > - better working and image directories meaning separation > - SortFunctions composable > - better OSWindow support > - convert rules to the Renraku architecture > - class and method comments improvements > - extensible Playground (pageActionOrder:) > - optional password management for command line handlers > - system dependencies tests > - unify way to obtain package manifests

Dec. 23, 2018

Re: [Pharo-dev] Pharo 7 changelog proposal

by Denis Kudriashov

Remove trait related items from calypso Ð²Ñ, 23 Ð´ÐµÐº. 2018 Ð³., 11:29 Pavel Krivanek pavel.krivanek(a)gmail.com: > Hi, > > I'm trying to summarize the changelog for Pharo 7 (based on about 2500 > merged PRs, not counting standalone commits to Iceberg and Calypso). If > something more should be mentioned, please let me know. > > Revolutionary kernel changes > - bootstrap > - modular stateful traits > - traits flattening in kernel packages > - new sources file for every bootstrapped version, empty changes > - new class builder > - binary packages loading (Hermes) > > Infrastructure changes > - switch to GitHub > - Tonel code format > - update building infrastructure to Jenkins 2 > > Code management > - Calypso, the new system browser > - new navigation model > - faster UI > - tabs toolbar instead of single source code panel > - explicit commands instead of duplicated menu and shortcuts > - extendable by plugins > - suitable for the remote scenario > - "dynamic protocols", support multiple tags per method > - not required star convention for class extension > - support multiple tags per class > - visibility option for inherited methods > - methods inherited from traits are not shown by default > - variable view as the special mode for method group view. > - better keyboard navigation > - and many more > > Iceberg > - a new friendly user interface > - simplification of solving problems with repositories > - workflow simplification > - better GitHub, BitBucket, GitLab support > - improved code merging and comparisons > - new code serialization format (Tonel) > - repositories metadata > - documentation > - better error handling, tags support > - improved Iceberg-Metacello integration > - credentials store > > Cleanups > - remove Nautilus > - remove UpdateStream > - remove all Configurations > - remove ShoreLine-Report > - remove TxText > - remove PluggableTabBarMorph > - remove the old Compiler > - remove Watery theme > - remove Versionner > - remove Komitter > - remove LegacyWeakSubscription > - continue on deprecation of FileStream > - dead code cleanups > - code organization cleanups > - unify categorization of common methods > - cleanups of object inspection protocol > - start with Ring deprecation > - better structure of packages > - package comments > > Updates > - Zinc > - Epicea > - FFI > - Metacello > - Fuel > > New > - Calypso > - integrate WebBrowser > - integrate ReferenceFinder > - Hermes > - Refactoring 2 > - Commander > - ClassAnnotation > > Spec > - ComposableModel renamed to ComposablePresenter > - new calendar presenter > - Spec-Demo > - improve Spec linking to domain models > > Look & Feel > - use the white theme by default > - improve themes switching > - main menu bar > - new window management shortcuts > - better support of fallback bitmap fonts > - improved Inspector refreshing > - Spotter is looking for opened windows > - display scale factor > - FastTable improvements > > VM interface > - DoubleWord and DoubleByte arrays > - add EncoderForSistaV1 > - read-only literals support > - improvements and fixes for 64-bit support > - fixes for FullBlockClosure > - support of the new bytecode set > > Reflectivity > - breakpoints improvements > - test coverage using metalinks > - reflectivity and metalinks improvements > > Other > - startup running in a fresh process > - better pin messages > - NewValueHolder and Model API unification > - better working and image directories meaning separation > - SortFunctions composable > - better OSWindow support > - convert rules to the Renraku architecture > - class and method comments improvements > - extensible Playground (pageActionOrder:) > - optional password management for command line handlers > - system dependencies tests > - unify way to obtain package manifests >

Dec. 23, 2018

Re: [Pharo-dev] Pharo 7 changelog proposal

by Ben Coman

On Sun, 23 Dec 2018 at 19:29, Pavel Krivanek <pavel.krivanek(a)gmail.com> wrote: > Hi, > > I'm trying to summarize the changelog for Pharo 7 (based on about 2500 > merged PRs, not counting standalone commits to Iceberg and Calypso). If > something more should be mentioned, please let me know. > > Other > - startup running in a fresh process > - better pin messages > - NewValueHolder and Model API unification > - better working and image directories meaning separation > - SortFunctions composable > - better OSWindow support > - convert rules to the Renraku architecture > - class and method comments improvements > - extensible Playground (pageActionOrder:) > - optional password management for command line handlers > - system dependencies tests > - unify way to obtain package manifests > - streamlined delay scheduler hierarchy, default changed to DelaySemaphoreScheduler cheers -ben

Dec. 23, 2018

Re: [Pharo-dev] Pharo 7 changelog proposal

by phil＠highoctane.be

Cool. Calypso and multiple tags per method is not really functional at this point. Phil On Sun, Dec 23, 2018, 12:29 Pavel Krivanek <pavel.krivanek(a)gmail.com wrote: > Hi, > > I'm trying to summarize the changelog for Pharo 7 (based on about 2500 > merged PRs, not counting standalone commits to Iceberg and Calypso). If > something more should be mentioned, please let me know. > > Revolutionary kernel changes > - bootstrap > - modular stateful traits > - traits flattening in kernel packages > - new sources file for every bootstrapped version, empty changes > - new class builder > - binary packages loading (Hermes) > > Infrastructure changes > - switch to GitHub > - Tonel code format > - update building infrastructure to Jenkins 2 > > Code management > - Calypso, the new system browser > - new navigation model > - faster UI > - tabs toolbar instead of single source code panel > - explicit commands instead of duplicated menu and shortcuts > - extendable by plugins > - suitable for the remote scenario > - "dynamic protocols", support multiple tags per method > - not required star convention for class extension > - support multiple tags per class > - visibility option for inherited methods > - methods inherited from traits are not shown by default > - variable view as the special mode for method group view. > - better keyboard navigation > - and many more > > Iceberg > - a new friendly user interface > - simplification of solving problems with repositories > - workflow simplification > - better GitHub, BitBucket, GitLab support > - improved code merging and comparisons > - new code serialization format (Tonel) > - repositories metadata > - documentation > - better error handling, tags support > - improved Iceberg-Metacello integration > - credentials store > > Cleanups > - remove Nautilus > - remove UpdateStream > - remove all Configurations > - remove ShoreLine-Report > - remove TxText > - remove PluggableTabBarMorph > - remove the old Compiler > - remove Watery theme > - remove Versionner > - remove Komitter > - remove LegacyWeakSubscription > - continue on deprecation of FileStream > - dead code cleanups > - code organization cleanups > - unify categorization of common methods > - cleanups of object inspection protocol > - start with Ring deprecation > - better structure of packages > - package comments > > Updates > - Zinc > - Epicea > - FFI > - Metacello > - Fuel > > New > - Calypso > - integrate WebBrowser > - integrate ReferenceFinder > - Hermes > - Refactoring 2 > - Commander > - ClassAnnotation > > Spec > - ComposableModel renamed to ComposablePresenter > - new calendar presenter > - Spec-Demo > - improve Spec linking to domain models > > Look & Feel > - use the white theme by default > - improve themes switching > - main menu bar > - new window management shortcuts > - better support of fallback bitmap fonts > - improved Inspector refreshing > - Spotter is looking for opened windows > - display scale factor > - FastTable improvements > > VM interface > - DoubleWord and DoubleByte arrays > - add EncoderForSistaV1 > - read-only literals support > - improvements and fixes for 64-bit support > - fixes for FullBlockClosure > - support of the new bytecode set > > Reflectivity > - breakpoints improvements > - test coverage using metalinks > - reflectivity and metalinks improvements > > Other > - startup running in a fresh process > - better pin messages > - NewValueHolder and Model API unification > - better working and image directories meaning separation > - SortFunctions composable > - better OSWindow support > - convert rules to the Renraku architecture > - class and method comments improvements > - extensible Playground (pageActionOrder:) > - optional password management for command line handlers > - system dependencies tests > - unify way to obtain package manifests >

Dec. 23, 2018

Re: [Pharo-dev] stfx.eu down

by phil＠highoctane.be

Yes, very welcome!! Phil On Sun, Dec 23, 2018, 09:59 Stephane Ducasse <stepharo.self(a)gmail.com wrote: > Thanks Sven!!! > > On Sat, Dec 22, 2018 at 8:13 PM Sven Van Caekenberghe <sven(a)stfx.eu> > wrote: > > > > > > > > > On 11 Dec 2018, at 21:23, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > > > > > >> On 10 Dec 2018, at 22:10, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > > >> > > >> Hi, > > >> > > >> This evening I somehow broke my stfx.eu server while doing an ubuntu > dist upgrade (an old AWS EC2 machine). > > >> > > >> This means several websites / web services hosted by that machine are > down, most notably mc.stfx.eu (hosting several of my packages) and > ws.stfx.eu (used for shared smalltalk workspaces). A couple of Zinc tests > will also fail. > > > > > > I recovered parts of the functionality: ws.stfx.eu (shared smalltalk > workspaces) and zn.stfx.eu are back, so that normal Zinc unit tests > should pass everywhere. > > > > > > At least all this is now running on Ubuntu 18.04.1 LTS on Pharo 7 > 64-bit, as it should. > > > > > > Next up is http://mc.stfx.eu for my Monticello repository, but that > might take more time. > > > > At last, http://mc.stfx.eu is back up. > > > > I still recommend everyone to use the http://github.com/svenvc versions > of my projects, as this is the better option going forward. I also intend > to use these as primary repositories. > > > > >> For source code access, all my public repos exist both in an up to > date form on GitHub (http://github.com/svenvc) as well in the original > form in SmalltalkHub (http://smalltalkhub.com/#!/~SvenVanCaekenberghe) or > SS3. > > >> > > >> The main problem there is that the distributed ConfigurationsOf and > Catalog entries will still point to the original. This is not a problem > with git's BaselineOf definitions. > > >> > > >> Although the machine will no longer boot, I managed to mount the > original volume on another instance so I can still access the whole > filesystem. This will make it possible to eventually recover most services. > But this will take time as these things never happen when it is convenient. > It will give me an opportunity to modernise the setup though, which is good. > > >> > > >> Sorry for the inconvenience. > > >> > > >> Sven > > >> > > > > > > > > >

Dec. 23, 2018

Re: [Pharo-dev] stfx.eu down

by Stephane Ducasse

Thanks Sven!!! On Sat, Dec 22, 2018 at 8:13 PM Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > > > > > On 11 Dec 2018, at 21:23, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > > > >> On 10 Dec 2018, at 22:10, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > >> > >> Hi, > >> > >> This evening I somehow broke my stfx.eu server while doing an ubuntu dist upgrade (an old AWS EC2 machine). > >> > >> This means several websites / web services hosted by that machine are down, most notably mc.stfx.eu (hosting several of my packages) and ws.stfx.eu (used for shared smalltalk workspaces). A couple of Zinc tests will also fail. > > > > I recovered parts of the functionality: ws.stfx.eu (shared smalltalk workspaces) and zn.stfx.eu are back, so that normal Zinc unit tests should pass everywhere. > > > > At least all this is now running on Ubuntu 18.04.1 LTS on Pharo 7 64-bit, as it should. > > > > Next up is http://mc.stfx.eu for my Monticello repository, but that might take more time. > > At last, http://mc.stfx.eu is back up. > > I still recommend everyone to use the http://github.com/svenvc versions of my projects, as this is the better option going forward. I also intend to use these as primary repositories. > > >> For source code access, all my public repos exist both in an up to date form on GitHub (http://github.com/svenvc) as well in the original form in SmalltalkHub (http://smalltalkhub.com/#!/~SvenVanCaekenberghe) or SS3. > >> > >> The main problem there is that the distributed ConfigurationsOf and Catalog entries will still point to the original. This is not a problem with git's BaselineOf definitions. > >> > >> Although the machine will no longer boot, I managed to mount the original volume on another instance so I can still access the whole filesystem. This will make it possible to eventually recover most services. But this will take time as these things never happen when it is convenient. It will give me an opportunity to modernise the setup though, which is good. > >> > >> Sorry for the inconvenience. > >> > >> Sven > >> > > > >

Dec. 23, 2018

Pharo 7 changelog proposal

by Pavel Krivanek

Hi, I'm trying to summarize the changelog for Pharo 7 (based on about 2500 merged PRs, not counting standalone commits to Iceberg and Calypso). If something more should be mentioned, please let me know. Revolutionary kernel changes - bootstrap - modular stateful traits - traits flattening in kernel packages - new sources file for every bootstrapped version, empty changes - new class builder - binary packages loading (Hermes) Infrastructure changes - switch to GitHub - Tonel code format - update building infrastructure to Jenkins 2 Code management - Calypso, the new system browser - new navigation model - faster UI - tabs toolbar instead of single source code panel - explicit commands instead of duplicated menu and shortcuts - extendable by plugins - suitable for the remote scenario - "dynamic protocols", support multiple tags per method - not required star convention for class extension - support multiple tags per class - visibility option for inherited methods - methods inherited from traits are not shown by default - variable view as the special mode for method group view. - better keyboard navigation - and many more Iceberg - a new friendly user interface - simplification of solving problems with repositories - workflow simplification - better GitHub, BitBucket, GitLab support - improved code merging and comparisons - new code serialization format (Tonel) - repositories metadata - documentation - better error handling, tags support - improved Iceberg-Metacello integration - credentials store Cleanups - remove Nautilus - remove UpdateStream - remove all Configurations - remove ShoreLine-Report - remove TxText - remove PluggableTabBarMorph - remove the old Compiler - remove Watery theme - remove Versionner - remove Komitter - remove LegacyWeakSubscription - continue on deprecation of FileStream - dead code cleanups - code organization cleanups - unify categorization of common methods - cleanups of object inspection protocol - start with Ring deprecation - better structure of packages - package comments Updates - Zinc - Epicea - FFI - Metacello - Fuel New - Calypso - integrate WebBrowser - integrate ReferenceFinder - Hermes - Refactoring 2 - Commander - ClassAnnotation Spec - ComposableModel renamed to ComposablePresenter - new calendar presenter - Spec-Demo - improve Spec linking to domain models Look & Feel - use the white theme by default - improve themes switching - main menu bar - new window management shortcuts - better support of fallback bitmap fonts - improved Inspector refreshing - Spotter is looking for opened windows - display scale factor - FastTable improvements VM interface - DoubleWord and DoubleByte arrays - add EncoderForSistaV1 - read-only literals support - improvements and fixes for 64-bit support - fixes for FullBlockClosure - support of the new bytecode set Reflectivity - breakpoints improvements - test coverage using metalinks - reflectivity and metalinks improvements Other - startup running in a fresh process - better pin messages - NewValueHolder and Model API unification - better working and image directories meaning separation - SortFunctions composable - better OSWindow support - convert rules to the Renraku architecture - class and method comments improvements - extensible Playground (pageActionOrder:) - optional password management for command line handlers - system dependencies tests - unify way to obtain package manifests

Dec. 23, 2018

Re: [Pharo-dev] stfx.eu down

by Sven Van Caekenberghe

> On 11 Dec 2018, at 21:23, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > >> On 10 Dec 2018, at 22:10, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: >> >> Hi, >> >> This evening I somehow broke my stfx.eu server while doing an ubuntu dist upgrade (an old AWS EC2 machine). >> >> This means several websites / web services hosted by that machine are down, most notably mc.stfx.eu (hosting several of my packages) and ws.stfx.eu (used for shared smalltalk workspaces). A couple of Zinc tests will also fail. > > I recovered parts of the functionality: ws.stfx.eu (shared smalltalk workspaces) and zn.stfx.eu are back, so that normal Zinc unit tests should pass everywhere. > > At least all this is now running on Ubuntu 18.04.1 LTS on Pharo 7 64-bit, as it should. > > Next up is http://mc.stfx.eu for my Monticello repository, but that might take more time. At last, http://mc.stfx.eu is back up. I still recommend everyone to use the http://github.com/svenvc versions of my projects, as this is the better option going forward. I also intend to use these as primary repositories. >> For source code access, all my public repos exist both in an up to date form on GitHub (http://github.com/svenvc) as well in the original form in SmalltalkHub (http://smalltalkhub.com/#!/~SvenVanCaekenberghe) or SS3. >> >> The main problem there is that the distributed ConfigurationsOf and Catalog entries will still point to the original. This is not a problem with git's BaselineOf definitions. >> >> Although the machine will no longer boot, I managed to mount the original volume on another instance so I can still access the whole filesystem. This will make it possible to eventually recover most services. But this will take time as these things never happen when it is convenient. It will give me an opportunity to modernise the setup though, which is good. >> >> Sorry for the inconvenience. >> >> Sven >> >

Dec. 22, 2018

Re: [Pharo-dev] [Moose-dev] Re: glamorous toolkit: v0.4.0

by Ben Coman

On Sat, 22 Dec 2018 at 06:03, Offray Vladimir Luna CÃ¡rdenas <offray.luna(a)mutabit.com> wrote: > > Hi, > > I share your feeling of wonder and also concern Luke. > > In my case, I used (old) GT tools to prototype Grafoscopio and now that the PhD thesis is practically done and only dissertation is pending, I would like to prepare myself to migrate Grafoscopio to Pharo 7, including bug fixing, stability, improved functionality, Iceberg for code management (but supporting Fossil instead of Git). > > I think that there is a lot of possibilities in the new GT tools and I like some of them going into interactive documentation (a line I was trying to explore with Pharo using Grafoscopio). But anytime I tried to use it I stumble upon a stop: > > First time was something related with me having some kind of credential enabled in GitHub to simple use it. I lost a whole morning just enabling that and reporting it. Was this on Windows? What was the fix for worked for you? (sorry its easier to ask again than try to identify in the archives a previous mention) cheers -ben > It was related with some mozilla library for font redering that didn't work well at the end. > Today I tried with the prebuild Linux image and Pharo Launcher, but I got an error message about inability to determine proper VM and when I tried installing it from Pharo 7 I got something related with a MemoryFileWriteStream dependency to be resolved before proper installation. > > I understand that this is alpha software and demos look amazing, but just running them requires a lot of work that previous GT didn't require. > > This brings me this feeling that these jumps in Pharo put core of the user experience at risk (kind of) and you end wondering how much an old tech will be maintained once the jump to the new shinny stuff is done and which is the migration path. > > In my case, I would like to have something like a Zeroconf script that just takes care of the external libraries, VM and image, to have a real glipmse of the upcoming future, beside the Tweets (which look great BTW). Maybe it will happen in a year or two, once it is properly integrated with Pharo, Zeroconf and thought for "end users" of interactive documents, which don't want to enable GitHub stuff, deal with external rendering dependencies and so on. Now the experience of using GT is kind of hostile for that users. > > Anyway, keep the good work and sharing it. Hopefully at some point it will reach the beta status, where users like myself can use it smoothly and build on GT's promises and interesting features. > > Cheers, > > Offray > > On 21/12/18 10:59, Luke Gorrie wrote: > > On Thu, 20 Dec 2018 at 10:58, Tudor Girba <tudor(a)tudorgirba.com> wrote: >> >> The goal of the new GT is to propose a completely reshaped programming experience that enables moldable development. You will find the concepts from the old GT in the new world as well. For example, the Inspector is extensible in similar ways and the API is similar as well. > > [...] >> >> Does this address the concern? > > > I am not sure yet :). > > Programming is not our main use case for GT. We are using GT as an object inspector (etc) for examining diagnostic data. We have a Smalltalk application that's similar to GDB and we are using GT as the front-end. > > In our world we use the Inspector and the Spotter but all of the Smalltalk programming views are hidden. GT is "molded" to be a diagnostic tool *instead of* a programming environment. Specifically, our main use case is inspecting/debugging the operation of a JIT compiler written in C. We have Smalltalk code to load binary coredumps from the JIT, decode them using DWARF debug information, and represent the application-level compiler data structures as Smalltalk objects. This way we can use GT to browse generated code, cross-reference profiler data, examine runtime compilation errors, etc. > > The "old" GT is awesome for this. I feel like this application is also very much in the spirit of the "moldable tools" thesis. Lots of diagnostic workflows ultimately boil down to drill-down inspecting and/or searching. > > I don't know where we stand with respect to the "new" GT though. I am talking about diagnostics, you are talking about programming. I am talking about zeros and ones, you are talking about feelings. I am maintaining a stable application, you are talking about rewrites. I am having a hard time whether I should be switching to the new GT in the immediate future, or waiting another year or two for it to mature, or planning to stick with the old GT. > > Hints would be appreciated :) > > I reiterate that I think you guys are doing fantastic work - some of the most interesting work in the programming universe to my mind. I hope that this discussion is useful for at least understanding the thought process of some users / potential users. > > Cheers! > -Luke > > > > _______________________________________________ > Moose-dev mailing list > Moose-dev(a)list.inf.unibe.ch > https://www.list.inf.unibe.ch/listinfo/moose-dev > > _______________________________________________ > Moose-dev mailing list > Moose-dev(a)list.inf.unibe.ch > https://www.list.inf.unibe.ch/listinfo/moose-dev

Dec. 21, 2018

Re: [Pharo-dev] [Moose-dev] Re: glamorous toolkit: v0.4.0

by Tudor Girba

Hi Offray, Thanks for describing your concerns. First, letâs address the technical part. Please go to gtoolkit.com and download the 64Bit distribution that includes the image and the VM. We will remove the standalone image option from the website until the VM situation gets clarified. Now, a clarification. The old GT was produced over a period of 4 years by an open-source team. The project had its own identity, and in 2014 the core of it was first integrated in Pharo. I say the core of it, because the visual part and other libraries are not in Pharo today. The full potential is found in Moose. In any case, during this process, GT got to be identified with Pharo and that was a good thing. The new GT is a product produced by feenk, a company. Much of the original team is still active in the new version, but now we commit to our product in a different way. The product is free and open-source, but itâs still a product with an identity and a goal. At present time, both the team, identity and goal are different than those of Pharo. Our goal is to offer a fundamentally new alternative to program (including comparing to what is possible now in Pharo). We are not looking for marginal improvements, and we are not aiming at backward compatibility. To build this alternative we invested in a whole new stack. That is not a tiny challenge and getting it right requires many iterations and feedback. We say we are in alpha not because of inconveniences of installation but because we are still very much developing the product. We announced the first alpha version in September and since then much has changed. At present time, we did manage to reach a situation where downloading the distribution should run on Mac, Linux and Windows. Even so, the current version is only for people that do want to try knowing that there will be hurdles. A word about the user experience. The current version runs inside the Pharo UI because we need to bootstrap. But, our goal is to build a complete IDE on the new stack. If you want to judge the user experience, it is only meaningful to do it within the GT windows, and not by comparing it with the rest of the existing Pharo UI. Does this clarify the situation? Cheers, Doru -- www.feenk.com "Every thing has its own flow." > On 21 Dec 2018, at 23:02, Offray Vladimir Luna CÃ¡rdenas <offray.luna(a)mutabit.com> wrote: > > Hi, > > I share your feeling of wonder and also concern Luke. > > In my case, I used (old) GT tools to prototype Grafoscopio and now that the PhD thesis is practically done and only dissertation is pending, I would like to prepare myself to migrate Grafoscopio to Pharo 7, including bug fixing, stability, improved functionality, Iceberg for code management (but supporting Fossil instead of Git). > > I think that there is a lot of possibilities in the new GT tools and I like some of them going into interactive documentation (a line I was trying to explore with Pharo using Grafoscopio). But anytime I tried to use it I stumble upon a stop: > > First time was something related with me having some kind of credential enabled in GitHub to simple use it. I lost a whole morning just enabling that and reporting it. It was related with some mozilla library for font redering that didn't work well at the end. > Today I tried with the prebuild Linux image and Pharo Launcher, but I got an error message about inability to determine proper VM and when I tried installing it from Pharo 7 I got something related with a MemoryFileWriteStream dependency to be resolved before proper installation. > I understand that this is alpha software and demos look amazing, but just running them requires a lot of work that previous GT didn't require. > This brings me this feeling that these jumps in Pharo put core of the user experience at risk (kind of) and you end wondering how much an old tech will be maintained once the jump to the new shinny stuff is done and which is the migration path. > > In my case, I would like to have something like a Zeroconf script that just takes care of the external libraries, VM and image, to have a real glipmse of the upcoming future, beside the Tweets (which look great BTW). Maybe it will happen in a year or two, once it is properly integrated with Pharo, Zeroconf and thought for "end users" of interactive documents, which don't want to enable GitHub stuff, deal with external rendering dependencies and so on. Now the experience of using GT is kind of hostile for that users. > > Anyway, keep the good work and sharing it. Hopefully at some point it will reach the beta status, where users like myself can use it smoothly and build on GT's promises and interesting features. > > Cheers, > > Offray >> On 21/12/18 10:59, Luke Gorrie wrote: >> On Thu, 20 Dec 2018 at 10:58, Tudor Girba <tudor(a)tudorgirba.com> wrote: >>> The goal of the new GT is to propose a completely reshaped programming experience that enables moldable development. You will find the concepts from the old GT in the new world as well. For example, the Inspector is extensible in similar ways and the API is similar as well. >> [...] >>> Does this address the concern? >> >> I am not sure yet :). >> >> Programming is not our main use case for GT. We are using GT as an object inspector (etc) for examining diagnostic data. We have a Smalltalk application that's similar to GDB and we are using GT as the front-end. >> >> In our world we use the Inspector and the Spotter but all of the Smalltalk programming views are hidden. GT is "molded" to be a diagnostic tool *instead of* a programming environment. Specifically, our main use case is inspecting/debugging the operation of a JIT compiler written in C. We have Smalltalk code to load binary coredumps from the JIT, decode them using DWARF debug information, and represent the application-level compiler data structures as Smalltalk objects. This way we can use GT to browse generated code, cross-reference profiler data, examine runtime compilation errors, etc. >> >> The "old" GT is awesome for this. I feel like this application is also very much in the spirit of the "moldable tools" thesis. Lots of diagnostic workflows ultimately boil down to drill-down inspecting and/or searching. >> >> I don't know where we stand with respect to the "new" GT though. I am talking about diagnostics, you are talking about programming. I am talking about zeros and ones, you are talking about feelings. I am maintaining a stable application, you are talking about rewrites. I am having a hard time whether I should be switching to the new GT in the immediate future, or waiting another year or two for it to mature, or planning to stick with the old GT. >> >> Hints would be appreciated :) >> >> I reiterate that I think you guys are doing fantastic work - some of the most interesting work in the programming universe to my mind. I hope that this discussion is useful for at least understanding the thought process of some users / potential users. >> >> Cheers! >> -Luke >> >> >> >> >> _______________________________________________ >> Moose-dev mailing list >> Moose-dev(a)list.inf.unibe.ch >> https://www.list.inf.unibe.ch/listinfo/moose-dev > _______________________________________________ > Moose-dev mailing list > Moose-dev(a)list.inf.unibe.ch > https://www.list.inf.unibe.ch/listinfo/moose-dev

Dec. 21, 2018

Re: [Pharo-dev] How can I wrap a byteArray into a stream

by Stephane Ducasse

I found it :) initializeWithByteArray: aByteArrayStream | A B C D | in := ZnBufferedReadStream on: aByteArrayStream. "Read the end-of-data value" A := in next bitAnd: 16rFF. B := (in next bitAnd: 16rff) << 8. C := (in next bitAnd: 16rff) << 16. D := (in next bitAnd: 16rff) << 24. eod := A bitOr: (B bitOr: (C bitOr: D)). "Skip the rest of the hashtable" in skip: 2048 - 4. "Current data pointer" pos := 2048 On Fri, Dec 21, 2018 at 10:44 PM Stephane Ducasse <stepharo.self(a)gmail.com> wrote: > > Of course this is not next but int16 :) > > > I will look further into > > testInt16Aliases > | input writer | > writer := [ :block | > ByteArray streamContents: [ :out | > ZnBufferedWriteStream on: out do: block ] ]. > input := ByteArray readHexFrom: '04D2'. > self assert: (ZnBufferedReadStream on: input readStream) int16 equals: 1234. > self assert: (ZnBufferedReadStream on: input readStream) uint16 equals: 1234. > self assert: (ZnBufferedReadStream on: input readStream) nextWord equals: 1234. > self assert: ((ZnBufferedReadStream on: input readStream) nextNumber: > 2) equals: 1234. > self assert: ((ZnBufferedReadStream on: input reversed readStream) > nextLittleEndianNumber: 2) equals: 1234. > self assert: (writer value: [ :out | out int16: 1234 ]) equals: input. > self assert: (writer value: [ :out | out uint16: 1234 ]) equals: input. > self assert: (writer value: [ :out | out nextWordPut: 1234 ]) equals: input. > self assert: (writer value: [ :out | out nextNumber: 2 put: 1234 ]) > equals: input. > self assert: (writer value: [ :out | out nextLittleEndianNumber: 2 > put: 1234 ]) equals: input reversed. > input := ByteArray readHexFrom: 'FB2E'. > self assert: (ZnBufferedReadStream on: input readStream) int16 equals: -1234. > self assert: (writer value: [ :out | out int16: -1234 ]) equals: input > > > > > > On Fri, Dec 21, 2018 at 10:40 PM Stephane Ducasse > <stepharo.self(a)gmail.com> wrote: > > > > Hi > > > > I'm fighting with super badly written code and my first reaction is a > > to be able to write tests and parametrize the code. > > > > I have some byteArray (contents of a CDB database) that I would like > > to manipulate using stream API. > > I'm looking for something like this > > > > ZnBinaryStream on: aByteArray; > > next; next; skip: 10; ... > > > > Stef

Dec. 21, 2018

Re: [Pharo-dev] How can I wrap a byteArray into a stream

by Stephane Ducasse

Of course this is not next but int16 :) I will look further into testInt16Aliases | input writer | writer := [ :block | ByteArray streamContents: [ :out | ZnBufferedWriteStream on: out do: block ] ]. input := ByteArray readHexFrom: '04D2'. self assert: (ZnBufferedReadStream on: input readStream) int16 equals: 1234. self assert: (ZnBufferedReadStream on: input readStream) uint16 equals: 1234. self assert: (ZnBufferedReadStream on: input readStream) nextWord equals: 1234. self assert: ((ZnBufferedReadStream on: input readStream) nextNumber: 2) equals: 1234. self assert: ((ZnBufferedReadStream on: input reversed readStream) nextLittleEndianNumber: 2) equals: 1234. self assert: (writer value: [ :out | out int16: 1234 ]) equals: input. self assert: (writer value: [ :out | out uint16: 1234 ]) equals: input. self assert: (writer value: [ :out | out nextWordPut: 1234 ]) equals: input. self assert: (writer value: [ :out | out nextNumber: 2 put: 1234 ]) equals: input. self assert: (writer value: [ :out | out nextLittleEndianNumber: 2 put: 1234 ]) equals: input reversed. input := ByteArray readHexFrom: 'FB2E'. self assert: (ZnBufferedReadStream on: input readStream) int16 equals: -1234. self assert: (writer value: [ :out | out int16: -1234 ]) equals: input On Fri, Dec 21, 2018 at 10:40 PM Stephane Ducasse <stepharo.self(a)gmail.com> wrote: > > Hi > > I'm fighting with super badly written code and my first reaction is a > to be able to write tests and parametrize the code. > > I have some byteArray (contents of a CDB database) that I would like > to manipulate using stream API. > I'm looking for something like this > > ZnBinaryStream on: aByteArray; > next; next; skip: 10; ... > > Stef

Dec. 21, 2018

How can I wrap a byteArray into a stream

by Stephane Ducasse

Hi I'm fighting with super badly written code and my first reaction is a to be able to write tests and parametrize the code. I have some byteArray (contents of a CDB database) that I would like to manipulate using stream API. I'm looking for something like this ZnBinaryStream on: aByteArray; next; next; skip: 10; ... Stef

Dec. 21, 2018

Re: [Pharo-dev] [Moose-dev] glamorous toolkit: v0.4.0

by Tudor Girba

And here is the tweet I was mentioning: https://twitter.com/feenkcom/status/1075011040373551104?s=21 Cheers, Doru -- www.feenk.com "Every thing has its own flow." > On 21 Dec 2018, at 21:32, Tudor Girba <tudor(a)tudorgirba.com> wrote: > > Hi, > > Thanks for detailing your thoughts. > > Indeed, I know about your application. Whatever you can do with the current GT you will be able to do with the new one. > > Except that for the new one you will be able to do extra things. Here are a few: > - You can build and share documents that embed those inspector views. This can be useful for reporting or sharing diagnostics with your users. > - Because the underlying rendering engine is much more powerful, you can express modern and interfaces that integrate with the rest of the environment smoothly. > - You likely have to deal with log files that might get large. First, the new editor allows you to smoothly work with such files. But, you can go well beyond this. Imagine that you build a tooling that produces the same editor only the text is interactive, and you might even embed visual artifacts right in the text to bridge the gap between what you would see in a typical console. For example, this tweet shows the new Transcript used to debug an animation. For every animation frame, we output the text corresponding with the frame and we insert the graphical preview corresponding to that step. > > You look at GT from the point of view of an end-user. You likely like the fact that you could mold the environment to your context and that you could do this incrementally. It happens that the same principles and tools can be applied to the whole programming, and once you do that, you actually can fundamentally change the act of programming. In fact, the same thing applies to the old GT: we built the new GT using that version and we believe that this allowed us to work much faster than if we would have used more traditional tools. The new GT pushes the envelope significantly further. > > So, that is why we are excited about that perspective, but even if you do not spend much time programming in Pharo, you can still take advantage for the user point of view as described above :). > > Is this answer better? > > Cheers, > Doru > > > >> On Dec 21, 2018, at 4:59 PM, Luke Gorrie <luke(a)snabb.co> wrote: >> >> On Thu, 20 Dec 2018 at 10:58, Tudor Girba <tudor(a)tudorgirba.com> wrote: >> The goal of the new GT is to propose a completely reshaped programming experience that enables moldable development. You will find the concepts from the old GT in the new world as well. For example, the Inspector is extensible in similar ways and the API is similar as well. >> [...] >> Does this address the concern? >> >> I am not sure yet :). >> >> Programming is not our main use case for GT. We are using GT as an object inspector (etc) for examining diagnostic data. We have a Smalltalk application that's similar to GDB and we are using GT as the front-end. >> >> In our world we use the Inspector and the Spotter but all of the Smalltalk programming views are hidden. GT is "molded" to be a diagnostic tool *instead of* a programming environment. Specifically, our main use case is inspecting/debugging the operation of a JIT compiler written in C. We have Smalltalk code to load binary coredumps from the JIT, decode them using DWARF debug information, and represent the application-level compiler data structures as Smalltalk objects. This way we can use GT to browse generated code, cross-reference profiler data, examine runtime compilation errors, etc. >> >> The "old" GT is awesome for this. I feel like this application is also very much in the spirit of the "moldable tools" thesis. Lots of diagnostic workflows ultimately boil down to drill-down inspecting and/or searching. >> >> I don't know where we stand with respect to the "new" GT though. I am talking about diagnostics, you are talking about programming. I am talking about zeros and ones, you are talking about feelings. I am maintaining a stable application, you are talking about rewrites. I am having a hard time whether I should be switching to the new GT in the immediate future, or waiting another year or two for it to mature, or planning to stick with the old GT. >> >> Hints would be appreciated :) >> >> I reiterate that I think you guys are doing fantastic work - some of the most interesting work in the programming universe to my mind. I hope that this discussion is useful for at least understanding the thought process of some users / potential users. >> >> Cheers! >> -Luke >> >> >> _______________________________________________ >> Moose-dev mailing list >> Moose-dev(a)list.inf.unibe.ch >> https://www.list.inf.unibe.ch/listinfo/moose-dev > > -- > www.feenk.com > > "Being happy is a matter of choice." > > > > >

Dec. 21, 2018

Re: [Pharo-dev] Downloading file with Zinc

by Stephane Ducasse

Tx This is strange since I looked for download and the system did not show it to me. Stef On Fri, Dec 21, 2018 at 9:55 AM Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > > > > > On 21 Dec 2018, at 05:25, Jimmie Houchin <jlhouchin(a)gmail.com> wrote: > > > > On 12/20/18 1:59 PM, Stephane Ducasse wrote: > >> Hi Sven > >> > >> I would like download files (pdf) with Zinc (not opening them in Pharo). > >> I wonder how I can do it with zinc. > >> > >> Tx > > > > 'http://files.pharo.org/books-pdfs/learning-oop/2018-04-01-LearningOOP.pdf' asZnUrl saveContentsToFile: '/mypath/mydir/learning-oop.pdf' > > > > Should get you going. > > > > Jimmie > > There is also ZnClient>>#downloadTo: > > ZnClient new url: ''; downloadTo: ''. > > Read the comment > >

Dec. 21, 2018

Re: [Pharo-dev] [Moose-dev] glamorous toolkit: v0.4.0

by Tudor Girba

Hi, Thanks for detailing your thoughts. Indeed, I know about your application. Whatever you can do with the current GT you will be able to do with the new one. Except that for the new one you will be able to do extra things. Here are a few: - You can build and share documents that embed those inspector views. This can be useful for reporting or sharing diagnostics with your users. - Because the underlying rendering engine is much more powerful, you can express modern and interfaces that integrate with the rest of the environment smoothly. - You likely have to deal with log files that might get large. First, the new editor allows you to smoothly work with such files. But, you can go well beyond this. Imagine that you build a tooling that produces the same editor only the text is interactive, and you might even embed visual artifacts right in the text to bridge the gap between what you would see in a typical console. For example, this tweet shows the new Transcript used to debug an animation. For every animation frame, we output the text corresponding with the frame and we insert the graphical preview corresponding to that step. You look at GT from the point of view of an end-user. You likely like the fact that you could mold the environment to your context and that you could do this incrementally. It happens that the same principles and tools can be applied to the whole programming, and once you do that, you actually can fundamentally change the act of programming. In fact, the same thing applies to the old GT: we built the new GT using that version and we believe that this allowed us to work much faster than if we would have used more traditional tools. The new GT pushes the envelope significantly further. So, that is why we are excited about that perspective, but even if you do not spend much time programming in Pharo, you can still take advantage for the user point of view as described above :). Is this answer better? Cheers, Doru > On Dec 21, 2018, at 4:59 PM, Luke Gorrie <luke(a)snabb.co> wrote: > > On Thu, 20 Dec 2018 at 10:58, Tudor Girba <tudor(a)tudorgirba.com> wrote: > The goal of the new GT is to propose a completely reshaped programming experience that enables moldable development. You will find the concepts from the old GT in the new world as well. For example, the Inspector is extensible in similar ways and the API is similar as well. > [...] > Does this address the concern? > > I am not sure yet :). > > Programming is not our main use case for GT. We are using GT as an object inspector (etc) for examining diagnostic data. We have a Smalltalk application that's similar to GDB and we are using GT as the front-end. > > In our world we use the Inspector and the Spotter but all of the Smalltalk programming views are hidden. GT is "molded" to be a diagnostic tool *instead of* a programming environment. Specifically, our main use case is inspecting/debugging the operation of a JIT compiler written in C. We have Smalltalk code to load binary coredumps from the JIT, decode them using DWARF debug information, and represent the application-level compiler data structures as Smalltalk objects. This way we can use GT to browse generated code, cross-reference profiler data, examine runtime compilation errors, etc. > > The "old" GT is awesome for this. I feel like this application is also very much in the spirit of the "moldable tools" thesis. Lots of diagnostic workflows ultimately boil down to drill-down inspecting and/or searching. > > I don't know where we stand with respect to the "new" GT though. I am talking about diagnostics, you are talking about programming. I am talking about zeros and ones, you are talking about feelings. I am maintaining a stable application, you are talking about rewrites. I am having a hard time whether I should be switching to the new GT in the immediate future, or waiting another year or two for it to mature, or planning to stick with the old GT. > > Hints would be appreciated :) > > I reiterate that I think you guys are doing fantastic work - some of the most interesting work in the programming universe to my mind. I hope that this discussion is useful for at least understanding the thought process of some users / potential users. > > Cheers! > -Luke > > > _______________________________________________ > Moose-dev mailing list > Moose-dev(a)list.inf.unibe.ch > https://www.list.inf.unibe.ch/listinfo/moose-dev -- www.feenk.com "Being happy is a matter of choice."

Dec. 21, 2018

[Pharo 7.0] Build #79: 22828-MethodFinder-Enhancement

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

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

Dec. 21, 2018

[Pharo 7.0] Build #78: 22775-Reflectivity-package-is-dirty

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

There is a new Pharo build available! The status of the build #78 was: SUCCESS. The Pull Request #2117 was integrated: "22775-Reflectivity-package-is-dirty" Pull request url: https://github.com/pharo-project/pharo/pull/2117 Issue Url: https://pharo.fogbugz.com/f/cases/22775 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Dec. 21, 2018

[Pharo 7.0] Build #77: Changed references to FileStream standard IO streams to Stdio.

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

There is a new Pharo build available! The status of the build #77 was: SUCCESS. The Pull Request #1966 was integrated: "Changed references to FileStream standard IO streams to Stdio." Pull request url: https://github.com/pharo-project/pharo/pull/1966 Issue Url: https://pharo.fogbugz.com/f/cases/22653 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Dec. 21, 2018

[Pharo 7.0] Build #76: Fix for issue 22729

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

There is a new Pharo build available! The status of the build #76 was: SUCCESS. The Pull Request #2045 was integrated: "Fix for issue 22729" Pull request url: https://github.com/pharo-project/pharo/pull/2045 Issue Url: https://pharo.fogbugz.com/f/cases/22729 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Dec. 21, 2018

[Pharo 7.0] Build #75: 22658-Better-manage-encoding-of-environment-variables

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

There is a new Pharo build available! The status of the build #75 was: FAILURE. The Pull Request #1980 was integrated: "22658-Better-manage-encoding-of-environment-variables" Pull request url: https://github.com/pharo-project/pharo/pull/1980 Issue Url: https://pharo.fogbugz.com/f/cases/22658 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Dec. 21, 2018

[Pharo 8.0] Build #1: 22825-Introduce-opaque

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

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

Dec. 21, 2018

[Pharo 7.0] Build #74: 22825-Introduce-opaque

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

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

Dec. 21, 2018

[Pharo 7.0] Build #73: 22400-Delays-are-not-working-properly

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

There is a new Pharo build available! The status of the build #73 was: FAILURE. The Pull Request #1873 was integrated: "22400-Delays-are-not-working-properly" Pull request url: https://github.com/pharo-project/pharo/pull/1873 Issue Url: https://pharo.fogbugz.com/f/cases/22400 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Dec. 21, 2018

[Pharo 7.0] Build #72: 22785 Refactor FFICompilerPlugin

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

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

Dec. 21, 2018

[Pharo 7.0] Build #71: 22813 Integer should return isAbstract with true

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

There is a new Pharo build available! The status of the build #71 was: SUCCESS. The Pull Request #2104 was integrated: "22813 Integer should return isAbstract with true" Pull request url: https://github.com/pharo-project/pharo/pull/2104 Issue Url: https://pharo.fogbugz.com/f/cases/22813 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Dec. 21, 2018

[Pharo 7.0] Build #70: 22774-Add-comments-to-SUnit

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

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

Dec. 21, 2018

Re: [Pharo-dev] Downloading file with Zinc

by Sven Van Caekenberghe

> On 21 Dec 2018, at 05:25, Jimmie Houchin <jlhouchin(a)gmail.com> wrote: > > On 12/20/18 1:59 PM, Stephane Ducasse wrote: >> Hi Sven >> >> I would like download files (pdf) with Zinc (not opening them in Pharo). >> I wonder how I can do it with zinc. >> >> Tx > > 'http://files.pharo.org/books-pdfs/learning-oop/2018-04-01-LearningOOP.pdf' asZnUrl saveContentsToFile: '/mypath/mydir/learning-oop.pdf' > > Should get you going. > > Jimmie There is also ZnClient>>#downloadTo: ZnClient new url: ''; downloadTo: ''. Read the comment

Dec. 21, 2018

Re: [Pharo-dev] Downloading file with Zinc

by Cyril Ferlicot

On Thu 20 Dec 2018 at 21:00, Stephane Ducasse <stepharo.self(a)gmail.com> wrote: > Hi Sven > > I would like download files (pdf) with Zinc (not opening them in Pharo). > I wonder how I can do it with zinc. > Hi, Here is a snippet with a progress bar if you want to give feedback to the user: https://github.com/Metacello/metacello/blob/master/repository/Metacello-Pla… > Tx > > -- Cyril Ferlicot https://ferlicot.fr

Dec. 21, 2018

[Pharo 7.0] Build #69: 22808 font infrastructure package should be fonts infrastructure

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

There is a new Pharo build available! The status of the build #69 was: FAILURE. The Pull Request #2100 was integrated: "22808 font infrastructure package should be fonts infrastructure" Pull request url: https://github.com/pharo-project/pharo/pull/2100 Issue Url: https://pharo.fogbugz.com/f/cases/22808 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Dec. 21, 2018

Re: [Pharo-dev] Downloading file with Zinc

by Jimmie Houchin

On 12/20/18 1:59 PM, Stephane Ducasse wrote: > Hi Sven > > I would like download files (pdf) with Zinc (not opening them in Pharo). > I wonder how I can do it with zinc. > > Tx 'http://files.pharo.org/books-pdfs/learning-oop/2018-04-01-LearningOOP.pdf' asZnUrl saveContentsToFile: '/mypath/mydir/learning-oop.pdf' Should get you going. Jimmie

Dec. 21, 2018

Downloading file with Zinc

by Stephane Ducasse

Hi Sven I would like download files (pdf) with Zinc (not opening them in Pharo). I wonder how I can do it with zinc. Tx

Dec. 20, 2018

[Pharo 7.0] Build #68: 22805-FTTableMorph-has-too-big-minimal-height

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

There is a new Pharo build available! The status of the build #68 was: SUCCESS. The Pull Request #2096 was integrated: "22805-FTTableMorph-has-too-big-minimal-height" Pull request url: https://github.com/pharo-project/pharo/pull/2096 Issue Url: https://pharo.fogbugz.com/f/cases/22805 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Dec. 20, 2018

[Pharo 7.0] Build #67: 22821 Cleanup Exception class

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

There is a new Pharo build available! The status of the build #67 was: SUCCESS. The Pull Request #2111 was integrated: "22821 Cleanup Exception class" Pull request url: https://github.com/pharo-project/pharo/pull/2111 Issue Url: https://pharo.fogbugz.com/f/cases/22821 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Dec. 20, 2018

[Pharo 7.0] Build #66: 22819 Cleanup TestReviver

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

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

Dec. 20, 2018

Re: [Pharo-dev] [Moose-dev] Re: glamorous toolkit: v0.4.0

by Tudor Girba

Hi Luke, I am happy this looks exciting :). About the confusion part: The Glamorous Toolkit we are working on right now is a complete new world built on a complete new graphical stack that does is not based on the existing stack that ships with Pharo. It is not an evolution. It is a leap. The goal of the new GT is to propose a completely reshaped programming experience that enables moldable development. You will find the concepts from the old GT in the new world as well. For example, the Inspector is extensible in similar ways and the API is similar as well. But, in the new world, we are bringing the concept much further. For example, Documenter provides a whole new kind of a tool that can mold to unify multiple workflows (like data notebooks, code documentation, or tutorials) right in the IDE. Coder provides the infrastructure for manipulating code that can mold its shape as you type. Transcript allows you to embed various widgets to transform the otherwise dull experience of a console into a live one. Behind the scenes GT comes with several engines. The Examples engine enables example-driven development which also bridges the gap between testing and documentation effort, especially when combined with Documenter. Releaser is able to release deeply nested projects. Phlow offers an engine that shares similarities with Glamour. Completer provides moldable completion. Visualizer offers a couple of visualization engines such as Mondrian. All of these are possible because of the underlying graphical stack made of Sparta/Bloc/Brick. All in all, we believe that the new GT enables a new way of programming. Individual features can be attractive, but our goal is to reshape the development experience. Does this address the concern? Cheers, Doru > On Dec 19, 2018, at 2:09 PM, Luke Gorrie <luke(a)snabb.co> wrote: > > On Fri, 14 Dec 2018 at 05:13, Tudor Girba <tudor(a)tudorgirba.com> wrote: > Please do let us know what you think .. and, of course, what you feel. > > I'm feeling excited and confused :). > > Excited because I love seeing all these new demos streaming out and I'm itching to put new capabilities to work. > > Confused about the roadmap. How does this "new" Glamorous Toolkit relate to the "old" one that I learned about last year from the Moldable Tools thesis? Is this a new version or a complete rewrite? Is it backwards compatible or completely reimagined? Is adopting the new version a seamless process or is porting required? Are frameworks like Glamour still there behind the scenes or were they replaced? etc. > > > <gt-documenter-magic-markup.gif><gt-0-4-0.png>_______________________________________________ > Moose-dev mailing list > Moose-dev(a)list.inf.unibe.ch > https://www.list.inf.unibe.ch/listinfo/moose-dev -- www.feenk.com "Things happen when they happen, not when you talk about them happening."

Dec. 20, 2018

[Pharo 7.0] Build #65: 22818 Cleanup Regex tests

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

There is a new Pharo build available! The status of the build #65 was: FAILURE. The Pull Request #2109 was integrated: "22818 Cleanup Regex tests" Pull request url: https://github.com/pharo-project/pharo/pull/2109 Issue Url: https://pharo.fogbugz.com/f/cases/22818 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Dec. 20, 2018

[Pharo 7.0] Build #64: 22814-Broken-comments-on-Cursor

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

There is a new Pharo build available! The status of the build #64 was: SUCCESS. The Pull Request #2106 was integrated: "22814-Broken-comments-on-Cursor" Pull request url: https://github.com/pharo-project/pharo/pull/2106 Issue Url: https://pharo.fogbugz.com/f/cases/22814 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Dec. 20, 2018

[Pharo 7.0] Build #63: 22811 Fix comment in ExternalBrowser

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

There is a new Pharo build available! The status of the build #63 was: SUCCESS. The Pull Request #2102 was integrated: "22811 Fix comment in ExternalBrowser" Pull request url: https://github.com/pharo-project/pharo/pull/2102 Issue Url: https://pharo.fogbugz.com/f/cases/22811 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Dec. 19, 2018

[Pharo 7.0] Build #62: 22812 Clean the ImageCleaner

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

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

Dec. 19, 2018

[Pharo 7.0] Build #61: 22809 Cleanup MethodFinderTest and related sample classes

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

There is a new Pharo build available! The status of the build #61 was: FAILURE. The Pull Request #2101 was integrated: "22809 Cleanup MethodFinderTest and related sample classes" Pull request url: https://github.com/pharo-project/pharo/pull/2101 Issue Url: https://pharo.fogbugz.com/f/cases/22809 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Dec. 19, 2018

Re: [Pharo-dev] Catalog Entries

by Sven Van Caekenberghe

> On 19 Dec 2018, at 10:58, Alistair Grant <akgrant0710(a)gmail.com> wrote: > > Hi Sven, > > On Wed, 19 Dec 2018 at 10:46, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: >> >> >> >>> On 19 Dec 2018, at 08:50, Alistair Grant <akgrant0710(a)gmail.com> wrote: >>> >>> Hi Sven, >>> >>> On Tue, 18 Dec 2018 at 12:55, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: >>>> >>>> I know about master and what it means, but that is not exactly what I want. >>>> >>>> When you release, that is a deliberate action: you put a stamp on the current project timeline, declaring it as ready/stable enough for people to depend on. >>>> >>>> The master branch can further evolve after a (latest) release. It is the next release candidate. >>>> >>>> I would like to depend on whatever released version is the latest. See the URLs in my previous email. >>> >>> I think your understanding of master is different from mine. master >>> should never be the next release candidate, it is only ever the latest >>> GA code. >>> >>> In that case, you can use master to mean "the latest GA version". >>> >>> If you want release candidates, they should be branches off >>> development (or tags). >>> >>> If you want to support multiple versions, e.g. be able to release a >>> 4.1 after 5.0 has been released, then each version should be branched >>> off master (at the GA commit for that version). >>> >>> If you want to know where a named GA version is (and there won't be >>> further updates), it is a tag on the master branch. >> >> I don't think/believe there is only one right way to use git, that is part of its power. > > Agreed, and I can see how you read my reply that way, but I didn't > mean to imply that "this is the one and only right way to do it". > > >> In our eco system, with #stable and #bleedingEdge / #development versions of ConfigurationsOf, it is my experience that very few people test before something is released. Hence the only way to get feedback is to release. Only if something has proven itself to be stable for some time can it receive a release tag, IMHO. > > OK, so what I understand you're try to achieve is to have a "released" > version and a "released and better tested" version. > > Doesn't this run the same risk of people just sticking to the > "released and better tested" version, so the "released" version never > gets the additional testing that's desired? Yes, that is the question ;-) >> I also want to make things as simple as possible. > > :-) > > Cheers, > Alistair

Dec. 19, 2018

[Pharo 7.0] Build #60: 22777 ManifestMonticello and ManifestRingMonticello should be tagged with "Manifest"

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

There is a new Pharo build available! The status of the build #60 was: SUCCESS. The Pull Request #2076 was integrated: "22777 ManifestMonticello and ManifestRingMonticello should be tagged with "Manifest"" Pull request url: https://github.com/pharo-project/pharo/pull/2076 Issue Url: https://pharo.fogbugz.com/f/cases/22777 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Dec. 19, 2018