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

Re: [Pharo-dev] New Year Wishlist (2018) ?

by Ben Coman

On 24 December 2017 at 00:58, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > Hi everybody, > > This looks like a good moment of the year to ask all of you what would you > want to see in Pharo next year. > Features, improvements, radical changes, etcâ¦. whatever you want. > > Of course, this list will not be a roadmap and it does not means we will > implement all of it (as always, time drives our possibilities), but is a > good moment for us a a community to check where we are and where we wan to > go next :) > > So, letâs those wishes come! Small enhancement that arises as I'm trying to design a Morph, Initially forgetting which corner of the screen is 0@0, raises the idea that in the GTInspector Morph tab, showing the coordinates of the mouse as it tracks over the morph would be useful. Maybe this would be less useful for Morphic using absolute co-ordinates, but good for Bloc using relative co-ordinates (IIUC). cheers -ben

Jan. 5, 2018

Soup Bug? Pre Tags Should Be Nestable

by Sean P. DeNigris

I did some research and don't see any restriction on nested pre tags, yet Soup includes <pre> in "NonNestableBlockTagsForHtml". This causes the following to be parsed as two sibling <pre> tags: <pre> Hi there <pre> This act shall take effect immediately. </pre> </pre> Moving <pre> from NonNestableBlockTagsForHtml to NestableBlockTagsForHtml seems to be The Right Thing To Do. Any objection (I'm certainly not an HTML expert). If not, I'll commit to my GH fork and feel free to merge back to StHub or wherever. ----- Cheers, Sean -- Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html

Jan. 4, 2018

[MoreVMs'18] Call for Contributions: 2nd Workshop on Modern Language Runtimes, Ecosystems, and VMs at <Programming> 2018

by Stefan Marr

============================================================================ Call for Papers: MoreVMs'18 2nd Workshop on Modern Language Runtimes, and Ecosystems Co-located with <Programming>'18 April 9th, 2018, Nice, France https://2018.programming-conference.org/track/MoreVMs-2018 ============================================================================ The MoreVMs'18 workshop aims to bring together industrial and academic programmers to discuss the design, implementation, and usage of modern languages and runtimes. This includes aspects such as reuse of language runtimes, modular implementation, language design and compilation strategies. The workshop aims to enable a diverse discussion on how languages and runtimes are currently being utilized, and where they need to improve further. We welcome presentation proposals in the form of extended abstracts discussing experiences, work-in-progress, as well as future visions, from either an academic or industrial perspective. Relevant topics include, but are definitely not limited to, the following: - Extensible VM design (compiler- or interpreter-based VMs) - Reusable components (e.g. interpreters, garbage collectors, ...) - Static and dynamic compilation techniques - Techniques for targeting high-level languages such as JavaScript - Interoperability between languages - Tooling support (e.g. debugging, profiling, etc.) - Programming language development environments - Case studies of existing language implementation approaches - Language implementation challenges and trade-offs - Surveys and usage reports to understand usage in the wild - Ideas for more predictable performance - Ideas for how VMs could take advantage of new hardware features - Ideas for how we should build languages in the future Workshop Format and Submissions ------------------------------- Submissions should use the ACM Conference acmart Format with the âsigconfâ option with a font size of 10 point and the font family Times New Roman. All submissions should be in PDF format. If you use LaTeX or Word, please use the provided ACM acmart templates. Otherwise, please follow the ACM author instructions. https://www.acm.org/publications/proceedings-template If you are formatting your paper using LaTeX, you will need to set the 10pt option in the \documentclass command. If you are formatting your paper using Word, you may wish to use the provided Word template that supports this font size. Please include page numbers in your submission for review using the LaTeX command \settopmatter{printfolios=true} (see examples in template). Please also ensure that your submission is legible when printed on a black and white printer. In particular, please check that colors remain distinct and font sizes are legible. Submission Site: https://easychair.org/conferences/?conf=morevms18 Important Dates --------------- Extended abstract submission: 2018-01-26 Author notification: 2018-02-23 Workshop: 2018-04-09 All deadlines are Anywhere on Earth (AoE), i.e. GMT/UTC-12:00 hour. Program Committee ----------------- ClÃ©ment Bera, Inria Lille Nord Europe, France Maxime Chevalier-Boisvert, University of Montreal, Canada SÃ©bastien Doeraene, EPFL, Switzerland Johan Fabry, Raincode Labs, Belgium Juliana Franco, Imperial College London, United Kingdom Tobias Grosser, ETH Zurich, Switzerland Ben L. Titzer, Google, Germany Niko Matsakis, Mozilla Research, United States Armin Rigo, PyPy, Switzerland Maoni Stephens, Microsoft, United States GaÃ«l Thomas, Telecom SudParis, France Mario Wolczko, Oracle Labs, United States Workshop Organizers ------------------- Edd Barrett, King's College London, United Kingdom Adam Welc, Uber Technologies, United States Stefan Marr, University of Kent, United Kingdom

Jan. 4, 2018

[Pharo 7.0-dev] Build #408: 20916 Use category "utilities" instead of "utils" in Kernel classes

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

There is a new Pharo build available! The status of the build #408 was: SUCCESS. The Pull Request #640 was integrated: "20916 Use category "utilities" instead of "utils" in Kernel classes" Pull request url: https://github.com/pharo-project/pharo/pull/640 Issue Url: https://pharo.fogbugz.com/f/cases/20916 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Jan. 4, 2018

[Pharo 7.0-dev] Build #407: 20920 RPackageOrganizer should use packageClass instead of RPackage references

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

There is a new Pharo build available! The status of the build #407 was: FAILURE. The Pull Request #648 was integrated: "20920 RPackageOrganizer should use packageClass instead of RPackage references" Pull request url: https://github.com/pharo-project/pharo/pull/648 Issue Url: https://pharo.fogbugz.com/f/cases/20920 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Jan. 4, 2018

Re: [Pharo-dev] How to restore image upgrade? was New Year Wishlist (2018) ?

by Guillermo Polito

On Tue, Dec 26, 2017 at 11:36 PM, Nicolas Cellier < nicolas.cellier.aka.nice(a)gmail.com> wrote: > > > 2017-12-25 23:54 GMT+01:00 Ben Coman <btc(a)openinworld.com>: > >> As a half-way house, consider that "upgrade" scripts could be a good >> mechanism >> post-Release when changes should be less-deep/less-arduous on the system. >> This might avoid Esteban's time being needed to re-Release for each >> upgrade, >> with post-Release moving to a more community supported mechanism. >> This could scale better as we gain more users interested in long term >> support >> of their applications on a stable-release than the moving target of the >> development-edge. >> >> cheers -ben >> > > Hi Ben, > upgrade scripts is what is used by Squeak trunk (as available via > Monticello). > it's difficult to write correctly, and difficult to test (clearly a job > for a bot). > Every intermediate script has to be replayed (or not, but who knows?) and > this is done via MonticelloConfigurationMap. > Can you imagine that transposed to git? > > It's not reversible (we don't provide the reverse scripts). > It might fail due to specific changes in the image (let's say dirty > workspace), and not only code changes. > > So it's very very far from git smoothness. > Fortunately, those scripts are rarely needed (as a percentage of commits). > Unfortunately, they are regularly needed (several times a year). > Remind that Pharo is supposed to change Kernel classes a bit faster than > Squeak ;) > > >> On 25 December 2017 at 23:11, Stephane Ducasse <stepharo.self(a)gmail.com> >> wrote: >> >>> Nicolas >>> >>> We want to keep the live part of Pharo and incremental loading and it >>> is key for us. Now we should not be naive. >>> >> > Hi Steph, > Not every provocation deserves an answer ;) > I hope everyone here wants a lively thing, otherwise why use Pharo? > > >> Most of the time we do not have the garantee that a change will work >>> when loaded. >>> >>> We have bots passing tests for rejecting broken code. > But the problem is that correct code can also be rejected > > We proposed Pablo to work since two years on a really working dynamic >>> code loader and >>> Pablo has really nice results. But it takes time to evaluate if/how we >>> integrate its changes. >>> Pablo has an atomic coder loader and an incremental and modular class >>> builder. >>> He also designed a modular shutdown/startup list manager (in production). >>> >>> Glad to ear that. I hope to read publications on this subject one day > then. > Two years for nice intermediate results just confirms that the problem is > very tough as we all know... > > We want to be able to have a **real** and robust incremental load. >>> Right now as you know it and as in ANY smalltalk I can break the >>> system super easily. >>> There is no magic. I do not see how we can make sure that any piece of >>> code will be loaded >>> and do not break the system. >>> So our objective is to have a new infrastructure that we can updates >>> (like method hashes for example without having to >>> twists our mind and do five updates). >>> >>> Now about git, we want and we will have our lovely image as a working >>> directory but this requires engineering >>> because the image is another artefact that other languages do not have >>> to worry. >>> We will get there. >>> >>> > Agree with all you said, > > My point is that git is not going to help you solving the problems others > don't have. > If we have seemless integration for bootstrap free code, that will already > be something... > For the rest, it's a bit too much wishful thinking to my taste. > As said above, because bootstrap problems happen rarely, but regularly, > I can predict that pharo development won't be as smooth as dreamed of for > some time. > We have to accept that and work hard to find acceptable trade offs. > I'm interested in seeing which solution will emerge. > In any case, the problem of updating pharo itself is a problem we have had for some time. And it is not specific to git and it is even shared with monticello. We lack of an atomic update with (a) object migration rules and (b) correct suspension of processes to avoid stack corruption. That is really difficult to make explicit manually in a script. > > > Stef >>> >>> >>> On Sun, Dec 24, 2017 at 11:41 PM, Nicolas Cellier >>> <nicolas.cellier.aka.nice(a)gmail.com> wrote: >>> > >>> > >>> > 2017-12-24 2:59 GMT+01:00 Alexandre Bergel <alexandre.bergel(a)me.com>: >>> >> >>> >> My four wishes, in no particular order: >>> >> - Better code completion >>> >> - Git in Pharo as easy as using Git for other languages >>> > >>> > The recipe is easy: turn pharo into a file based edit-compile-run >>> language >>> > and expunge those live object burden ;) >>> > Let me explain why it's not just trolling. >>> > Currently we have to download an image made by a bot. >>> > Pharo has gradually lost the power to upgrade the image (it's not new). >>> > >>> > If we recognize that an image acts like a workspace, and want to let >>> the >>> > pull/branch switch/etc work again... >>> > IOW going from one point to any other in source code graph >>> > and experience the full power of git like any other language, >>> > that means, in a live IDE, at least solving those two problems: >>> > - changing the tools that are used to upgrade the image (Compiler, >>> > MethodDictionary, Array, etc...) >>> > - correctly initialize all the states (including stange loops) >>> > If pharo has not managed to solve this with a linear one way history >>> (the >>> > regularly broken update image option), >>> > how do you think this is going to be solved in the more general case? >>> > I call this the universal boostrap problem. >>> > >>> > IMO the logical next step is to separate the IDE >>> > (the Inanimate Desintegrated Environment of any other language). >>> > >>> > Maybe we don't have to bend Pharo too much to git if it does not fit. >>> > The goal: as easy might be not that easy. >>> > >>> > >>> >> - Bloc on Steroid >>> >> - Being able to interrupt any process and endless loop using >>> Cmd-. >>> >> >>> >> Merry Christmas to all of you! >>> >> Alexandre >>> >> >>> >> >>> >> >>> >> > On Dec 23, 2017, at 1:58 PM, Esteban Lorenzano <estebanlm(a)gmail.com >>> > >>> >> > wrote: >>> >> > >>> >> > Hi everybody, >>> >> > >>> >> > This looks like a good moment of the year to ask all of you what >>> would >>> >> > you want to see in Pharo next year. >>> >> > Features, improvements, radical changes, etcâ¦. whatever you want. >>> >> > >>> >> > Of course, this list will not be a roadmap and it does not means we >>> will >>> >> > implement all of it (as always, time drives our possibilities), but >>> is a >>> >> > good moment for us a a community to check where we are and where we >>> wan to >>> >> > go next :) >>> >> > >>> >> > So, letâs those wishes come! >>> >> > >>> >> > cheers, >>> >> > Esteban >>> >> >>> >> >>> > >>> >>> >> > -- 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

Jan. 4, 2018

Re: [Pharo-dev] Replacement for deprected MultiByteFileStream?

by Guillermo Polito

On Tue, Jan 2, 2018 at 1:13 PM, Henrik Sperre Johansen < henrik.s.johansen(a)veloxit.no> wrote: > Stephane Ducasse-3 wrote > > Hi Bernhard > > > > Have a look at how guille started to implement File package. > > (Guille is actively converting all the image users of the old > > hierarchy but last time he losts a couple of hours > > because changing epicea and other users of positionable streams and > > sourceArray... at the same time > > was leading to complex situations :). But Guille told me that he > > learned and will come back to this.) > > > > He is using ZnCharacterWriteStream and wrapper like > > ZnCrPortableWriteStream. > > > > writeSourceCodeFrom: aStream baseName: baseName isSt: stOrCsFlag > > > > | extension fileName outputStream | > > extension := stOrCsFlag ifTrue: ['.st'] ifFalse: ['.cs']. > > fileName := baseName, extension. > > fileName := FileSystem disk checkName: fileName fixErrors: true. > > outputStream := (File named: fileName) writeStream. > > (ZnCrPortableWriteStream on: (ZnCharacterWriteStream > > on: outputStream > > encoding: 'utf8')) nextPutAll: aStream contents. > > > > outputStream close. > > > > writeSourceCodeFrom: aStream toFileReference: aFileReference > > > > aFileReference writeStreamDo: [ :outputStream | > > (ZnCrPortableWriteStream on: (ZnCharacterWriteStream > > on: outputStream > > encoding: 'utf8')) nextPutAll: aStream contents. > > ]. > > > > self inform: 'Filed out to: ', String cr, aFileReference basename > > > > > > self inform: 'Filed out to: ', String cr, fileName. > > > > I hope it helps. > > > > Stef > > > > On Sat, Dec 30, 2017 at 1:27 PM, Bernhard Pieber < > > > bernhard@ > > > > wrote: > >> I just saw that the FileStream hierarchy including MultiByteFileStream > is > >> deprecated. However, I can't find what file stream class should be used > >> to read a UTF-8 encoded file instead. FileReference>>#readStreamDo: also > >> uses MultiByteFileStream. > >> > >> Can someone please point me to the right code? > >> > >> Bernhard > > Maybe it's just me, but I'd a big fan of convenience methods over explicit > stacking when it comes to multi-layer streams. > - It documents the intended/valid ways to stack (such as which streams it > makes sense to wrap in a ZnCrPortableWriteStream, or which streams one > normally would want to #buffered:do:) > - It makes the transition (in terms of conciseness) from "traditional" > filestreams less jarring (provided convenience methods provide sensible > defaults). > > Say, for instance, a #withEncoding:do:* on read/writeStream, so instead of > the above, one can do: > > fileName := FileSystem disk checkName: fileName fixErrors: true. > (outputStream :=(File named: fileName) writeStream) > withEncoding: 'utf8' > do: [:encodedWriteStream | > encodedWriteStream nextPutAll: aStream contents]. > outputStream close. > > and > aFileReference writeStreamDo: [ :outputStream | > outputStream withEncoding: 'utf8' do: [:encodedStream | > encodedStream nextPutAll: aStream contents. ]]. > or > input := aFileReference readStreamDo: [ :inputStream | > inputStream withEncoding: 'utf8' do: [:decodingStream | > decodingStream contents]] > > It's more involved than the current multibytestreams, but takes away the > burden of determining the correct stack of ZnStreams for the common case. > For instance, you'd normally want file write streams to also be wrapped by > a > buffered stream, and have a single flush at end of withEncoding:do:, while > the same isn't necessary for withEncoding:do: on the base WriteStream > class. > It's not just you :). I was during last sprint (while seeing such idioms appear) adding convenience methods like writeStreamEncoded: anEncoding writeStreamDo: aBlock encoded: anEncoding readStreamEncoded: anEncoding readStreamDo: aBlock encoded: anEncoding But my image fantastically crashed, the save image failed and I lost everything... > Cheers, > Henry > > *Bad name, I know, but you get the point. > > > > -- > Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html > > -- 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

Jan. 4, 2018

Re: [Pharo-dev] Iceberg merged pull requests?

by Esteban Lorenzano

> On 3 Jan 2018, at 23:09, Stephane Ducasse <stepharo.self(a)gmail.com> wrote: > > You should double click on the pharo lines and looks in the update > pane you will see the updates (but you should pull from pharo to sync > your repo). > > Stef > > On Tue, Jan 2, 2018 at 10:45 PM, Bernhard Pieber <bernhard(a)pieber.com> wrote: >> I saw that two pull requests were accepted and merged into the development branch. I had expected that Iceberg would show me them somewhere. However, in the branches pane of my repository the status pharo-project/development is shown as Up to date. >> >> Shouldn't there be some indication that new code is available to be merged, or am I misunderstanding Iceberg? you are misunderstanding iceberg :) your repository shows the status of the image against your local copy of the repository, not the remote one. If you want to see those changes, you need to first âfetchâ the remote repository (which will update the commits available in the local one). this is a task (fetching) that other tools do in background time to time (for example, sourcetree does it like when you focus on the window), to show this as a âlive experienceâ, but we cannot do the same because a call to fetch would block the image (since FFI is blocking for the moment), then you will need to do that by hand until we get threaded FFI. also, notice that updating Pharo from iceberg is a very bad idea, and you can have an unusable image after that (update other projects will usually work). Esteban >> >> Bernhard >

Jan. 4, 2018

about copyAllTo:

by Stephane Ducasse

Hi I have the gut feeling that copyAllTo: is not really nice because unclear. The comments are unclear on the "flattening" It is unclear that it flattens the leaves or not. I mean A B x C D y z A copyAllTo: K do we get K B x C D y z or K x y z We got touched by such difference and the message name is not enough intention revealing. I would prefer a message copyAsSuchTo: copyLeavesTo: What do you think? Stef

Jan. 3, 2018

Re: [Pharo-dev] Iceberg merged pull requests?

by Stephane Ducasse

You should double click on the pharo lines and looks in the update pane you will see the updates (but you should pull from pharo to sync your repo). Stef On Tue, Jan 2, 2018 at 10:45 PM, Bernhard Pieber <bernhard(a)pieber.com> wrote: > I saw that two pull requests were accepted and merged into the development branch. I had expected that Iceberg would show me them somewhere. However, in the branches pane of my repository the status pharo-project/development is shown as Up to date. > > Shouldn't there be some indication that new code is available to be merged, or am I misunderstanding Iceberg? > > Bernhard

Jan. 3, 2018