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

Re: [Pharo-dev] Anyone else seen crashes like these ?

by Cyril Ferlicot

On Mon, Nov 12, 2018 at 2:37 PM Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > > Hi, > > I run Pharo 7 64-bit on a macOS laptop, where the images are kept running across sleep/wake cycles. > > For many weeks, it often happens that an image crashes before/after such a sleep/wakeup (not all the time, just regularly). > > Here is a crash dump from today (fresh image/vm from WE, nothing special loaded). > > Related to scheduling ? Event handling ? > Hi, I switched to an macOS at the beginning of October and since I often have this kind of behavior. > > -- Cyril Ferlicot https://ferlicot.fr

Nov. 12, 2018

Anyone else seen crashes like these ?

by Sven Van Caekenberghe

Hi, I run Pharo 7 64-bit on a macOS laptop, where the images are kept running across sleep/wake cycles. For many weeks, it often happens that an image crashes before/after such a sleep/wakeup (not all the time, just regularly). Here is a crash dump from today (fresh image/vm from WE, nothing special loaded). Related to scheduling ? Event handling ?

Nov. 12, 2018

Re: [Pharo-dev] Better management of encoding of environment variables

by Ben Coman

On Mon, 12 Nov 2018 at 18:02, Guillermo Polito <guillermopolito(a)gmail.com> wrote: > 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 > > I haven't been using environment variables a lot so I don't have a strong technical opinion (although at a glance it makes reasonable sense). But I wanted to say I really like the way you've presented your offline discussion, conclusions and proposal. Thanks. cheers -ben

Nov. 12, 2018

[Pharo 7.0-dev] Build #1378: 22651-URL-color-is-hardcoded-in-welcome-window

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

There is a new Pharo build available! The status of the build #1378 was: FAILURE. The Pull Request #1972 was integrated: "22651-URL-color-is-hardcoded-in-welcome-window" Pull request url: https://github.com/pharo-project/pharo/pull/1972 Issue Url: https://pharo.fogbugz.com/f/cases/22651 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

Nov. 12, 2018

[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