- Pharo-dev - lists.pharo.org

[Pharo 7.0-dev] Build #1377: 22649-Remove DelaySpinScheduler

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

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

Nov. 12, 2018

Better management of encoding of environment variables

by Guillermo Polito

Hi all, following the meeting we had here @Inria headquarters, I'll be backporting some of the improvements we did in the launcher this last month regarding the encoding of environment variables. I've opened for this issue https://pharo.fogbugz.com/f/cases/22658/ We have already studied possible alternatives with Pablo and Christophe and we have some conclusions and we propose some changes: API Proposal for OSEnvironment ========================= - *at: aVariableName * Gets the String value of an environment variable called `aVariableName` It is the system reponsibility to manage the encoding. Rationale: A common denominator for all platforms providing an already decoded string, because windows does not (compared to *nix systems) provide a encoded byte representation of the value. Windows has instead its own wide string representation. - *[optionally] rawAt: anEncodedVariableName* Gets the Byte value of an environment variable called `anEncodedVariableName`. It is the user responsibility to encode and decode argument and return values in the encoding of this preference. Rationale: Some systems may want to have the liberty to use different encodings, or even to put binary data in the variables. - *[optionally] at: aVariableName encoding: anEncoding* Gets the value of an environment variable called `aVariableName` using `anEncoding` to encode/decode arguments and return values. Rationale: *xes could potentially use different encodings for their environment variables or even use different encodings in different parts of their file system. Other Implementation details ========================= - VM primitives returning paths Strings should be carefuly managed to decode them, since they are actually C strings (so byte arrays) disguised as ByteStrings. - Windows requires calling the right *Wide version of the functions from C, plus the correct encoding routine. This could be implemented as an FFI call or by modifying the VM to do it properly instead of calling the Ascii version

Nov. 12, 2018

Esteban's ChangeLog week of 5 November 2018

by estebanlm＠gmail.com

Hello! This is my weekly ChangeLog, from 5 November 2018 to 11 November 2018. You can see it in a better format by going here: http://log.smallworks.eu/web/search?from=5/11/2018&to=11/11/2018 ChangeLog ========= 5 November 2018: ---------------- * I just [announced](http://forum.world.st/ANN-Pharo-v7-0-0-rc1-released-td5088221.html) Pharo v7.0.0-rc1. Now the real work begins... :P * I worked on [case: 22628](https://pharo.fogbugz.com/f/cases/22628): merge latest FFI-Kernel changes. Thing is, now there is some overlapping between FFI-Kernel and UnifiedFFI, because they changed it in some things we already solved in UFFI, but well... we will have to see this in the future :) * I made a small PR to add a fix that Eliot contributed to it: [https://github.com/pharo-vcs/tonel/pull/60](https://github.com/pharo-vcs/to… . Is an error that happens when a snapshot contains *only* method extensions. cheers! Esteban

Nov. 12, 2018

Re: [Pharo-dev] Excel export with Tabular

by Eric Gade

I want to second support for this effort. I had a freelance project a few months back that had a need to generate formatted Excel documents from external API data. It also needed an easy to use GUI for it's users. At the time I desperately wanted to use Pharo (since RAD tools on personal computers have sadly become an endangered species). Instead I was forced to make an Electronic app. In short, there is a real need for this out there and I feel like it goes understated. On Sun, Nov 11, 2018, 16:50 Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > Hi Hans-Martin, > > This is great. I use Tabular too and was missing active > development/maintenance. It would be very good to see this project move > forward. It is quite important/useful in enterprise contexts. > > Thx, > > Sven > > PS: where did you commit the changes ? any chance of moving it to GitHub > (too) ? > > > On 11 Nov 2018, at 22:16, Hans-Martin <pharo-dev(a)fam-mosner.de> wrote: > > > > Hello folks, > > I have a need for creating excel files with more than 3 worksheets, so I > > took the Tabular code and beefed up the exporter a little. It does handle > > more worksheets now, uses XMLWriter to create all the ZIP members, and is > > properly named now (the class was called TabularXSLXExport, note swapped > S > > and L). > > Some tests have been added, there are a number of items that I plan to > to as > > time allows: > > - Add (possibly limited) support for styles and formulas which I > > specifically need for the project I'm working on so I could write files > with > > the desired layout and functionality. > > - Add support for reading more aspects of XLSX files, preferrably as > much as > > needed to be able to read and write most files without loss. > > - Add rendering, maybe at the basic morphic level, maybe using something > > else as I'm not really up-to-date regarding the developments in Pharo. > > - Add formula evaluation. > > - Add editing capabilites to have a fully functional spreadsheet (really > far > > off). > > > > Cheers, > > Hans-Martin > > > > > > > > -- > > Sent from: > http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html > > > > >

Nov. 11, 2018

Re: [Pharo-dev] Excel export with Tabular

by Sven Van Caekenberghe

Hi Hans-Martin, This is great. I use Tabular too and was missing active development/maintenance. It would be very good to see this project move forward. It is quite important/useful in enterprise contexts. Thx, Sven PS: where did you commit the changes ? any chance of moving it to GitHub (too) ? > On 11 Nov 2018, at 22:16, Hans-Martin <pharo-dev(a)fam-mosner.de> wrote: > > Hello folks, > I have a need for creating excel files with more than 3 worksheets, so I > took the Tabular code and beefed up the exporter a little. It does handle > more worksheets now, uses XMLWriter to create all the ZIP members, and is > properly named now (the class was called TabularXSLXExport, note swapped S > and L). > Some tests have been added, there are a number of items that I plan to to as > time allows: > - Add (possibly limited) support for styles and formulas which I > specifically need for the project I'm working on so I could write files with > the desired layout and functionality. > - Add support for reading more aspects of XLSX files, preferrably as much as > needed to be able to read and write most files without loss. > - Add rendering, maybe at the basic morphic level, maybe using something > else as I'm not really up-to-date regarding the developments in Pharo. > - Add formula evaluation. > - Add editing capabilites to have a fully functional spreadsheet (really far > off). > > Cheers, > Hans-Martin > > > > -- > Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html >

Nov. 11, 2018

Excel export with Tabular

by Hans-Martin

Hello folks, I have a need for creating excel files with more than 3 worksheets, so I took the Tabular code and beefed up the exporter a little. It does handle more worksheets now, uses XMLWriter to create all the ZIP members, and is properly named now (the class was called TabularXSLXExport, note swapped S and L). Some tests have been added, there are a number of items that I plan to to as time allows: - Add (possibly limited) support for styles and formulas which I specifically need for the project I'm working on so I could write files with the desired layout and functionality. - Add support for reading more aspects of XLSX files, preferrably as much as needed to be able to read and write most files without loss. - Add rendering, maybe at the basic morphic level, maybe using something else as I'm not really up-to-date regarding the developments in Pharo. - Add formula evaluation. - Add editing capabilites to have a fully functional spreadsheet (really far off). Cheers, Hans-Martin -- Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html

Nov. 11, 2018

[Pharo 7.0-dev] Build #1376: 22656-Improve-ImageReadWriter-comments

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

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

Nov. 11, 2018

Re: [Pharo-dev] Streams and FileDialog in Pharo 6 and 7

by Denis Kudriashov

Ð¿Ð½, 29 Ð¾ÐºÑ. 2018 Ð³. Ð² 10:07, Guillermo Polito <guillermopolito(a)gmail.com>: > Well, there are still variants > - chooseFile* > - fileOpen* > - fileSave* > - chooseFileName* > - chooseFullFileName* > > I prefered rather to be explicit and to avoid confusion with the old API > (which I deprecated, not removed!) > Ok. For current situation it is probably the right thing to do. And monstrous names are easy to rename/deprecate in future. But I don't think that in clean system (without old API) using just a File in such names needs special explanation. Because we postulate that only file references are exposed to users. User chooses a file and Pharo gives him a reference to this file. > > On Sat, Oct 27, 2018 at 2:42 PM Denis Kudriashov <dionisiydk(a)gmail.com> > wrote: > >> What about different names? >> >> UIManager default >> chooseFileIn: aFileReference >> withExtensions: #() >> title: 'title' >> >> UIManager default >> chooseFileForSaveIn: aFileReference >> withExtensions: #() >> title: 'title' >> >> We can just expect file references because it is what is exposed to users >> in pharo file system. Not neccessery to put it in method name. >> >> Ð¿Ñ, 26 Ð¾ÐºÑ. 2018 Ð³., 16:32 Guillermo Polito <guillermopolito(a)gmail.com>: >> >>> Hi all, >>> >>> I've proposed a PR with some cleanups in this respect >>> >>> https://github.com/pharo-project/pharo/pull/1941 >>> >>> This is the proposed replacement API that returns file references >>> instead of streams or file names. >>> >>> "Get existing file reference" >>> UIManager default >>> chooseExistingFileReference: 'title' >>> extensions: nil >>> path: FileSystem workingDirectory. >>> >>> "Get existing file reference filtering by extensions" >>> UIManager default >>> chooseExistingFileReference: 'title' >>> extensions: #('log') >>> path: FileSystem workingDirectory. >>> >>> "Get existing file reference to file" >>> UIManager default >>> chooseExistingFileReference: 'title' >>> extensions: nil >>> path: FileSystem workingDirectory / 'PharoDebug.log'. >>> >>> "Get file reference for save (not necessarily existing)" >>> UIManager default >>> chooseForSaveFileReference: 'title' >>> extensions: #('log') >>> path: 'PharoDebuasdg.log'. >>> >>> On Fri, Oct 26, 2018 at 3:11 PM Guillermo Polito < >>> guillermopolito(a)gmail.com> wrote: >>> >>>> Ok, so can we agree on deprecating the non compatible methods and >>>> redirect the user to the new ones? >>>> >>>> To me, the problem with returning a stream is that from a user >>>> perspective you don't know: >>>> - is the file encoded or binary >>>> - if it is encoded, in which encoding? >>>> - if i receive an open file stream, and I want to delete that file I >>>> have to close it, retrieve the file, delete it? >>>> - IMHO, what is the worst: whose responsibility is it to close the >>>> file? >>>> >>>> On Thu, Sep 6, 2018 at 10:43 PM Peter Uhnak <i.uhnak(a)gmail.com> wrote: >>>> >>>>> > It should return a FileReference, not an open stream. I believe >>>>> there are methods that do that. >>>>> >>>>> There are different APIs for that. >>>>> >>>>> fileOpen*, as the name implies, _opens the file_ and returns the >>>>> stream. (I think this should be the case for fileSave*) >>>>> >>>>> If you want file reference, then you can use e.g. >>>>> >>>>> UIManager default chooseFileMatching: #() label: nil >>>>> >>>>> or `chooseFileMatching:label:`, >>>>> `chooseFileName:extensions:path:preview:`, >>>>> `chooseFullFileName:extensions:path:preview:`, >>>>> `chooseFullFileNameMatching:label:`. >>>>> Also some methods for selecting directories >>>>> (`chooseDirectory:path:`, chooseDirectory:from:`, ...) >>>>> >>>>> iirc some of them actually return String (file path) instead of >>>>> FileReference. ( >>>>> https://gist.github.com/peteruhnak/8ac6667b8eb11daee71517d0172b7355#file-ui… >>>>> ) >>>>> >>>>> So it can be confusing, but the API is already available. >>>>> >>>>> Also iirc UIManager should be preferred over UITheme builder. >>>>> >>>>> Peter >>>>> >>>>> On Thu, Sep 6, 2018 at 9:57 PM Sven Van Caekenberghe <sven(a)stfx.eu> >>>>> wrote: >>>>> >>>>>> >>>>>> >>>>>> > On 6 Sep 2018, at 21:37, Torsten Bergmann <astares(a)gmx.de> wrote: >>>>>> > >>>>>> > Hi, >>>>>> > >>>>>> > A question to those who worked on the new streams for Pharo 7: >>>>>> > >>>>>> > >>>>>> > In PHARO 6 I used the following expression to open a file dialog >>>>>> and let the user choose >>>>>> > a binary file: >>>>>> > >>>>>> > s := UITheme builder fileOpen: 'Choose a file' extensions: >>>>>> #('exe'). >>>>>> > >>>>>> > This returned >>>>>> > - either nil (when file dialog was canceled) >>>>>> > - a "MultiByteFileStream" instance when a file was selected >>>>>> > >>>>>> > The MultiByteFileStream instance already had the name of the file >>>>>> (= full path) and I was >>>>>> > able to query it for further use: >>>>>> > >>>>>> > s := UITheme builder fileOpen: 'Choose a file' extensions: #('exe'). >>>>>> > s name inspect >>>>>> > >>>>>> > (for instance to display which file is processed in a window by >>>>>> showing the full path) >>>>>> > >>>>>> > >>>>>> > >>>>>> > Now in PHARO 7 same expression returns an instance of >>>>>> ZnCharacterReadStream (as MultiByteFileStream >>>>>> > is deprecated): >>>>>> > >>>>>> > s := UITheme builder fileOpen: 'Choose a file' extensions: #('exe'). >>>>>> > >>>>>> > and ZnCharacterReadStream does not understand #name - and in fact >>>>>> the info about the name is >>>>>> > totally lost/not available. To me this looks missing/broken. >>>>>> > >>>>>> > So what is the recommended way in Pharo 7 to open a file dialog, >>>>>> let the use choose a file >>>>>> > and get a file stream but also the name? IMHO this is either broken >>>>>> or missing... >>>>>> > >>>>>> > Thanks >>>>>> > T. >>>>>> >>>>>> It should return a FileReference, not an open stream. I believe there >>>>>> are methods that do that. >>>>>> >>>>>> But that is an incompatible API change (same selector, different >>>>>> return type). So hard to decide. >>>>>> >>>>>> >>>>>> >>>> >>>> -- >>>> >>>> >>>> >>>> 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 >>>> >>> >>> >>> -- >>> >>> >>> >>> 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 >>> >> > > -- > > > > 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 >

Nov. 11, 2018

Re: [Pharo-dev] How do I create a binary stream

by Hilaire

I am quite happy with the new FileReference API. Le 11/11/2018 Ã 13:51, Sven Van Caekenberghe a Ã©critÂ : > API changes are always annoying, but splitting reading and writing as well as binary and character streams is a clear improvement overall. > -- Dr. Geo http://drgeo.eu

Nov. 11, 2018

Re: [Pharo-dev] How do I create a binary stream

by Sven Van Caekenberghe

> On 11 Nov 2018, at 10:29, Alistair Grant <akgrant0710(a)gmail.com> wrote: > > File is a low level API that is only used in limited circumstances, > e.g. bootstrapping when FileSystem isn't yet available. Another reason not to use File is because it is slower as it is unbuffered. For the following file $ file test.png test.png: PNG image data, 950 x 936, 8-bit/color RGBA, non-interlaced $ ls -la test.png -rw-r--r--@ 1 sven staff 241773 Nov 11 13:39 test.png I get [ ImageReadWriter formFromFileNamed: 'test.png' ] bench. "'8.725 per second'" [ ImageReadWriter formFromStream: 'test.png' asFileReference binaryReadStream ] bench. "'8.914 per second'" [ ImageReadWriter formFromStream: (File named: 'test.png') readStream ] bench. "'6.023 per second'" By preventing the auto detection of the type and the subclass lookup, we can improve a little bit more. [ PNGReadWriter formFromStream: 'test.png' asFileReference binaryReadStream ] bench. "'9.113 per second'" Sven

Nov. 11, 2018