- Pharo-dev - lists.pharo.org

glamorous toolkit - moldable method coder
by Tudor Girba Nov. 8, 2018

Nov. 8, 2018

Hi, We design the Glamorous Toolkit to enable moldable development. This is a new take on programming that is predicated on the idea that tools must adapt to the context of the software system in order to be effective. Until now, we mainly applied moldability to how we inspect/debug/search existing code and objects. The first incarnation of GT, the tools that are present in the Pharo distribution, already showed how moldable development can provide dramatic productivity gains, especially when combined with examples. To make the experience complete, more recently we started to build moldability into Coder, the new set of tools for creating code. The first tool we created is Method Coder, an editor for a single method. This is a working editor that has multiple new features, one of which being that it can be collapsed to only see the method pattern (header), and that the body is editable without affecting the method pattern. This editor is versatile and can be used in various places, such as class coder or a search: https://twitter.com/feenkcom/status/1058003761262743552 Yesterday, we reached a new milestone. In the example below we see how adding/removing <gtExample> to a method changes the shape of the method Coder dynamically without requiring a save. In our case, the changes affect: the example status label, the in-place example expanding toggle, and the run button. https://twitter.com/feenkcom/status/1060290294749560833 This just an example that is specific to the examples engine, but it shows how typing can be linked live to all details that make the surrounding tool. Of course, the mechanism behind the scene is available for you to adapt the editor to your code. This is a whole new uncharted world, and we think there is a great deal of potential in this area. Have fun, The feenk team -- www.feenk.com âHow do you feenk today?"

1 0

Cannot use Zinc in Pharo7 anymore
by Norbert Hartl Nov. 8, 2018

Nov. 8, 2018

I asked this before because I donât get it. External packages like Zinc seem to be modified when integrated into pharo. Looking at the changes between to newest Zinc from Svenâs repository and the one in pharo there are a few differences. As an example there is ZnCharacterReadWriteStream>>#tab writeStream tab Where is this method added? Are the changes pushed back to Sven? In my project I use Zinc-REST. So I need to add the repository for Zinc and load the REST group. When this is loaded it pulls in the other Zinc packages which removes the methods like the one above and my image gets stuck because Epicea relies on that method and I get a debugger. So at the moment I can only create a new image when I disable Epicea. Why is it done that way? Best would be to use the version from Sven and make changes there. If that is not possible it would be good to use an extra package that does extension methods to Zinc. But this way is asking for trouble IMHO. Norbert

11 31

Infinite error recursion while saving Pharo70 alpha
by Aliaksei Syrel Nov. 7, 2018

Nov. 7, 2018

Hello, When saving one of the latest pharo70 image I got an infinite recursion loop due to message not understood. Force closing it probably lead to image corruption and it became un-openable anymore. Any idea what is going on? It does not look like a unique case because there are a few pharo70 images that already died in front of me... [image: Screen Shot 2018-11-07 at 09.55.07.png] VM: Mac OS - x64 - 1013.5 - CoInterpreter VMMaker.oscog-eem.2461 uuid: > b3cd33f5-6309-43a1-b669-7a1805111f34 Oct 31 2018 > StackToRegisterMappingCogit VMMaker.oscog-eem.2464 uuid: > 0b1fa0a3-a781-4fd5-b1cf-1809796ccbbf Oct 31 2018 > VM: 201810311808 https://github.com/OpenSmalltalk/opensmalltalk-vm.git > Date: Wed Oct 31 11:08:29 2018 CommitHash: c7a9b1f Plugins: 201810311808 > https://github.com/OpenSmalltalk/opensmalltalk-vm.git > Image: Pharo7.0.0alpha [Build information: > Pharo-7.0.0+alpha.build.1361.sha.011b7c939adeb52338baad16a694cab2e7a54d74 > (64 Bit)] Cheers, Alex

5 7

[Pharo 7.0-dev] Build #1372: 22638-usage-of-readlink-f-breaks-macOS-bootstrap
by ci-pharo-ci-jenkins2＠inria.fr Nov. 7, 2018

Nov. 7, 2018

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

1 0

[Pharo 7.0-dev] Build #1371: 22641-Semantic-analysis-needs-to-take-instead-preambles-into-account
by ci-pharo-ci-jenkins2＠inria.fr Nov. 7, 2018

Nov. 7, 2018

There is a new Pharo build available! The status of the build #1371 was: SUCCESS. The Pull Request #1960 was integrated: "22641-Semantic-analysis-needs-to-take-instead-preambles-into-account" Pull request url: https://github.com/pharo-project/pharo/pull/1960 Issue Url: https://pharo.fogbugz.com/f/cases/22641 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

1 0

[ANN] Iceberg v1.4.0
by Cyril Ferlicot Nov. 7, 2018

Nov. 7, 2018

Hello! This week we are releasing the version v1.4.0 of Iceberg. (https://github.com/pharo-vcs/iceberg/releases/tag/v1.4.0) This version is available in the latest Pharo 7. This release fixes a bug introduced in v1.3. It also add new features in the repository view, add some cleaning and also re-introduce a feature that was lost. Thanks to all contributors. Enjoy! Full changelog: Bugfixes #1068 'There is no associated repository configured.' warning on right clicking missing repository Features #1077 Repository view: Allow to collapse branches/remotes/tags trees #847 Move tags under remotes in Repository view #1070 set upstream if missing Cleanups #1066 Pharo 7: PackageManifest subclasses should be packaged with "Manifest" #1015 Replace usages of Glamour in the Github Plugin #1063 1061-Introduce-iconNamed-in-IceDefinition-and-IceTipModel-and-remove-all-the-terrible-Smalltalk-ui-icons -- Cyril Ferlicot https://ferlicot.fr

2 1

[Pharo 7.0-dev] Build #1370: 22629-Secondary-selection-is-too-bright-when-switching-to-the-dark-theme
by ci-pharo-ci-jenkins2＠inria.fr Nov. 7, 2018

Nov. 7, 2018

There is a new Pharo build available! The status of the build #1370 was: FAILURE. The Pull Request #1953 was integrated: "22629-Secondary-selection-is-too-bright-when-switching-to-the-dark-theme" Pull request url: https://github.com/pharo-project/pharo/pull/1953 Issue Url: https://pharo.fogbugz.com/f/cases/22629 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

1 0

Slow writing to Transcript (stderr) in Windows 10 PharoConsole.exe -headless
by Christopher Fuhrman Nov. 7, 2018

Nov. 7, 2018

Hello, I encountered a performance bug in Pharo 6 under Windows 10 with Moose, starting from the Moose 6.1 (beta) image in Pharo Launcher. I migrated my code from Pharo 5 and it uses a PharoCommandLineHandler to load an MSE file, which sometimes has many (15K) warnings/errors. It was taking over a minute to run something that in Moose takes only a few seconds. To debug and make a minimal example, I removed the Moose file part of my CommandLineHandler and simulated the writing of errors (i/o) with a loop. I believe the I/O to the stderr is why the performance is bad. In Windows 10 Task Manager, I can see that the process is not using much CPU. As I recall, my code didn't have this performance problem in Pharo 5. The command in windows to execute my minimal sample is something like: C:\Users\me>Documents\Pharo\vms\61-x86\PharoConsole.exe -headless "C:\Users\me\Documents\Pharo\images\Moose Suite 6.1 (beta)\CommandHandler VM slow bug.image" mooseminer --msefile blah The last part (--msefile blah) is needed because I didn't want to remove the argument validation. Here's a copy of the image: https://www.dropbox.com/s/7cgt37lef2xh2ut/CommandHandler%20VM%20slow%20bug.… A workaround is to run without -headless (or to not have so many errors). I hope this is useful to someone. For RMOD people I'm happy to demo this on my machine. Cheers, -- Christopher Fuhrman, P.Eng, PhD *Professor in the DÃ©partement of Software and IT EngineeringÃTS (Ãcole de technologie supÃ©rieure)* http://profs.etsmtl.ca/cfuhrman +1 514 396 8638 *L'ÃTS est une constituante de l'UniversitÃ© du QuÃ©bec*

1 0

[ANN] Pharo v7.0.0-rc1 released!
by Esteban Lorenzano Nov. 7, 2018

Nov. 7, 2018

Greetings! Iâm announcing today we reach Pharo 7.0.0-rc1! This is the first step to release a definitive version, and while we will continue integrating bug fixes, API change Pull Requests will be delayed until the open of Pharo 8.0.0 development. Now, you would wonder what is the ChangeLog of this releaseâ¦ and answer is we still do not have one (btw, we should find a way to automate this). Anywayâ¦ we are very close to release now :) Please download, test, report issues. Esteban

4 3

Re: [Pharo-dev] [ANN] The STON Specification, Cog speed, and namespaces/modules
by Shaping Nov. 7, 2018

Nov. 7, 2018

Hi Eliot. Pharo (& Squeak & Cuis) Float subclass BoxedFloat64 maps exactly to VW's Double. In 64-bit SmallFloat64 maps exactly to SmallDouble. But I wonder whether there is any issue here. STON would use the print strings for (PSC) Float / (VW) Double, and so deseerialization on Pharo would automatically produce the right class. Going in the other direction might need some help. APF needs support in PSC before one can port, but are representable as suitably-sized word arrays. There is no support for __float128 anywhere in the VM (e.g. not even in the FFI) on PSC as yet. I see Pharoâs WordArray. Iâll work on an APF for Pharo, as time permits. Iâm using APFs in VW in the 300-bit range, and want to reduce the needed precision to 64 bits, to save space and time on large (5 million+) scalar time-series, both on the heap and during BOSSing (25 m save-time now). The problem is not so much an issue for the JulianDayNumber (JDN)-precision, which is adequate in this app at 14 to 15 digits (even though my JDN class subclasses APF, for now). Other calculations need the more extreme precision. I think I can make 128-bit floats work, and would really like to see a small, fast, boxed 128-bit float implementation in Pharo or VW. The APFs are big and slow. Where in the queue of planned improvements to Pharo does such a task lie? I suspect itâs not a very popular item. Broadening the issue somewhat, Iâm trying to find as many good reasons as possible to justify the work needed to port all my VW stuff to Pharo. Iâve seen the references to Cogâs speed and coming speed-up. Are there recent (say, in the last year) benchmarks comparing VW and Pharo? Any details here would be very much appreciated. Having no namespaces in Pharo is, I think, the biggest impediment. I prefer not to prefix class names, but there may be fewer name-collisions than I suppose--maybe none. Still, I need to know how VW and Pharo classes map in order to place overrides and extensions correctly. Besides the mentioned float-class mappings is there a reference on this? Object allSubclasses in Pharo 7 64-bit, produces 14946 classes. Pharo is a little bigger than it used to be. I suppose I donât need to check all unloaded packages because all classes in each of those will have the same unique prefix. Is that correct? Or, I could just load every package I can find, before I check names. But that little experiment has never gone well in the past. Is the Pharo-with-namespaces issue dead or merely suspended, awaiting a more fitting idea than what VW currently offers? Shaping On Tue, Nov 6, 2018 at 12:56 AM Shaping <shaping(a)uurda.org <mailto:shaping@uurda.org> > wrote: STON is able to serialise Pharoâs Floats, what do you mean by double ? Floating-point numbers in IEEE 64-bit format, 14 or 15 significant digits, with a range between =10^307 and 10^307. Additionally, I recently asked Sven if t would be possible to store ScaledDecimals (I think it implements what you call ArbitraryPrecisionFloats) without loss of precision. Iâm referring to VWâs Double (and SmallDouble in 64-bit engines/images). APFs are binary representations that can be arbitrarily large, using Integers (LargePositiveIntegers for example) to model the bits of the mantissa. Before, because STON extends JSON, it was storing all kind of numbers either as float or integer. Now, thanks to Sven, STON stores ScaledDecimals correctly (without loss of precision through serialisation as float, what was done before). But I do not know if this change is integrated in recent images yet. â¦.. Number subclass: #Float instanceVariableNames: '' classVariableNames: 'E Epsilon Halfpi Infinity Ln10 Ln2 MaxVal MaxValLn MinValLogBase2 NaN NegativeInfinity NegativeZero Pi RadiansPerDegree Sqrt2 ThreePi Twopi' poolDictionaries: '' category: 'Kernel-Numbers' My instances represent IEEE-754 floating-point double-precision numbers. They have about 16 digits of accuracy and their range is between plus and minus 10^307. Some valid examples are: 8.0 13.3 0.3 2.5e6 1.27e-30 1.27e-31 -12.987654e12 â¦. I see that Pharoâs Float is VWâs Double. So then I just need to be able to serialize APF. â¦. FIFloatType subclass: #FFIFloat128 instanceVariableNames: '' classVariableNames: '' poolDictionaries: '' category: 'UnifiedFFI-Types' I'm a 128bits (cuadruple precision) float. It is usually not used, but some compiler modes support it (__float128 in gcc) THIS IS NOT YET SUPPORTED â¦. The class above is also from the Pharo 7 image. This is the largest of the c-type FFIFloats. Any Float classes of this size and larger for the Smalltalk heap on 64-bit Pharo? Cheers, Shaping Le 6 nov. 2018 Ã 06:58, Shaping <shaping(a)uurda.org <mailto:shaping@uurda.org> > a Ã©crit : (Having domain problems recently. Please excuse this posting if you have seen it twice. I've not seen it appear yet on the list.) Can STON be extended to handle Doubles and ArbitraryPrecisionFloats? Shaping -----Original Message----- From: Pharo-dev [mailto:pharo-dev-bounces@lists.pharo.org] On Behalf Of David T. Lewis Sent: Wednesday, October 31, 2018 14:58 To: Pharo Development List <pharo-dev(a)lists.pharo.org <mailto:pharo-dev@lists.pharo.org> > Subject: Re: [Pharo-dev] [ANN] The STON Specification This is very clear and well written. Dave Hi, Since there can never be enough documentation I finally took some time to write a more formal description of STON as a data format. https://github.com/svenvc/ston/blob/master/ston-spec.md The idea is to let this stabilise a bit and to then update the two other documents describing STON, where necessary: https://github.com/svenvc/ston/blob/master/ston-paper.md https://ci.inria.fr/pharo-contribution/job/EnterprisePharoBook/lastSuc cessfulBuild/artifact/book-result/STON/STON.html Also, the latest changes in STON have to make their way to the Pharo image as well. https://github.com/svenvc/ston All feedback is welcome. Sven -- Sven Van Caekenberghe Proudly supporting Pharo http://pharo.org http://association.pharo.org http://consortium.pharo.org -- _,,,^..^,,,_ best, Eliot

1 0