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

[Pharo 7.0-dev] Build #436: 20942-Integrate-Epicea-826-in-Ph7

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

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

Jan. 18, 2018

Re: [Pharo-dev] Random corrupted data when copying from very large byte array

by Thierry Goubier

Hi Cyril, try with the last vms available at: https://bintray.com/opensmalltalk/vm/cog/ For example, the last Ubuntu 64bits vm is at: https://bintray.com/opensmalltalk/vm/cog/201801170946#files Regards, Thierry 2018-01-18 16:42 GMT+01:00 Cyrille Delaunay <cy.delaunay(a)gmail.com>: > Hi everyone, > > I just added a new bug entry for an issue we are experimenting since some > times: > > https://pharo.fogbugz.com/f/cases/20982/Random-corrupted- > data-when-copying-from-very-large-byte-array > > Here is the description: > > > *History:* > > This issue has been spotted after experimenting strange behavior with > seaside upload. > After uploading a big file from a web browser, the modeled file generated > within pharo image begins with 4 unexpected bytes. > This issue occurs randomly: sometimes the first 4 bytes are right. > Sometimes the first 4 bytes are wrong. > This issue only occurs with Pharo 6. > This issue occurs for all platforms (Mac, Ubuntu, Windows) > > *Steps to reproduce:* > > I have been able to set up a small scenario that highlight the issue. > > Download Pharo 6.1 on my Mac (Sierra 10.12.6): https://pharo.org/ > web/download > Then, iterate over this process till spotting the issue: > > => start the pharo image > => execute this piece of code in a playground > > 1: > 2: > 3: > 4: > 5: > 6: > > ZnServer startDefaultOn: 1701.ZnServer default maximumEntitySize: 80* 1024 * 1024.'/Users/cdelaunay/myzip.zip' asFileReference writeStreamDo: [ :out |out binary; nextPutAll: #[80 75 3 4 10 0 0 0 0 0 125 83 67 73 0 0 0 0 0 0].18202065 timesRepeat: [ out nextPut: 0 ]]. > > => Open a web browser page on: http://localhost:1701/form-test-3 > => Upload the file zip file previously generated ('myzip.zip'). > => If the web page displays: "contents=000000000a00 > <https://pharo.kilnhg.com/Search?search=000000000a00>..." (or anything > unexpected), THIS IS THE ISSUE ! > => If the web page displays: "contents=504b03040a00 > <https://pharo.kilnhg.com/Search?search=504b03040a00>..", the upload > worked fine. You can close the image (without saving) > > > > *Debugging:* > > > > Bob Arning has been able to reproduce the issue with my scenario. > He dived into the code involved during this process, till reaching some > "basic" methods where he saw the issue occuring. > > Here are the conclusion till there: > => A corruption occurs while reading an input stream with method ZnUtils > class>>readUpToEnd:limit: > The first 4 bytes may be altered randomely. > => The first 4 bytes are initially correctly written to an outputStream. > But, the first 4 bytes of this outputStream gets altered (corrupted), > sometimes when the inner byte array grows OR when performing the > final "outputStream contents" > => Here is a piece of code that reproduce the issue (still randomely. > stopping an restarting the image may change the behavior) > > 1: > 2: > 3: > 4: > 5: > 6: > 7: > 8: > 9: > 10: > 11: > 12: > 13: > 14: > 15: > 16: > 17: > 18: > 19: > 20: > > test4"self test4" | species bufferSize buffer totalRead outputStream answer inputStream ba byte1 | ba := ByteArray new: 18202085. ba atAllPut: 99. 1 to: 20 do: [ :i | ba at: i put: (#[80 75 3 4 10 7 7 7 7 7 125 83 67 73 7 7 7 7 7 7] at: i) ]. inputStream := ba readStream. bufferSize := 16384. species := ByteArray. > buffer := species new: bufferSize. > totalRead := 0. > outputStream := nil. > [ inputStream atEnd ] whileFalse: [ | readCount | > readCount := inputStream readInto: buffer startingAt: 1 count: bufferSize. > totalRead = 0 ifTrue: [ > byte1 := buffer first. > ]. > totalRead := totalRead + readCount. > > outputStream ifNil: [ > inputStream atEnd > ifTrue: [ ^ buffer copyFrom: 1 to: readCount ] > ifFalse: [ outputStream := (species new: bufferSize) writeStream ] ]. > outputStream next: readCount putAll: buffer startingAt: 1. > byte1 = outputStream contents first ifFalse: [ self halt ]. > ]. > answer := outputStream ifNil: [ species new ] ifNotNil: [ outputStream contents ]. > byte1 = answer first ifFalse: [ self halt ]. ^answer > > > > *suspicions* > > This issue appeared with Pharo 6. > > Some people suggested that it could be a vm issue, and to try my little > scenario with the last available vm. > > I am not sure where to find the last available vm. > > I did the test using these elements: > https://files.pharo.org/image/60/latest.zip > > https://files.pharo.org/get-files/70/pharo-mac-latest.zip/ > <https://files.pharo.org/get-files/70/> > > > > The issue is still present > > > > -- > Cyrille Delaunay >

Jan. 18, 2018

Random corrupted data when copying from very large byte array

by Cyrille Delaunay

Hi everyone, I just added a new bug entry for an issue we are experimenting since some times: https://pharo.fogbugz.com/f/cases/20982/Random-corrupted-data-when-copying-… Here is the description: *History:* This issue has been spotted after experimenting strange behavior with seaside upload. After uploading a big file from a web browser, the modeled file generated within pharo image begins with 4 unexpected bytes. This issue occurs randomly: sometimes the first 4 bytes are right. Sometimes the first 4 bytes are wrong. This issue only occurs with Pharo 6. This issue occurs for all platforms (Mac, Ubuntu, Windows) *Steps to reproduce:* I have been able to set up a small scenario that highlight the issue. Download Pharo 6.1 on my Mac (Sierra 10.12.6): https://pharo.org/web/download Then, iterate over this process till spotting the issue: => start the pharo image => execute this piece of code in a playground 1: 2: 3: 4: 5: 6: ZnServer startDefaultOn: 1701.ZnServer default maximumEntitySize: 80* 1024 * 1024.'/Users/cdelaunay/myzip.zip' asFileReference writeStreamDo: [ :out |out binary; nextPutAll: #[80 75 3 4 10 0 0 0 0 0 125 83 67 73 0 0 0 0 0 0].18202065 timesRepeat: [ out nextPut: 0 ]]. => Open a web browser page on: http://localhost:1701/form-test-3 => Upload the file zip file previously generated ('myzip.zip'). => If the web page displays: "contents=000000000a00 <https://pharo.kilnhg.com/Search?search=000000000a00>..." (or anything unexpected), THIS IS THE ISSUE ! => If the web page displays: "contents=504b03040a00 <https://pharo.kilnhg.com/Search?search=504b03040a00>..", the upload worked fine. You can close the image (without saving) *Debugging:* Bob Arning has been able to reproduce the issue with my scenario. He dived into the code involved during this process, till reaching some "basic" methods where he saw the issue occuring. Here are the conclusion till there: => A corruption occurs while reading an input stream with method ZnUtils class>>readUpToEnd:limit: The first 4 bytes may be altered randomely. => The first 4 bytes are initially correctly written to an outputStream. But, the first 4 bytes of this outputStream gets altered (corrupted), sometimes when the inner byte array grows OR when performing the final "outputStream contents" => Here is a piece of code that reproduce the issue (still randomely. stopping an restarting the image may change the behavior) 1: 2: 3: 4: 5: 6: 7: 8: 9: 10: 11: 12: 13: 14: 15: 16: 17: 18: 19: 20: test4"self test4" | species bufferSize buffer totalRead outputStream answer inputStream ba byte1 | ba := ByteArray new: 18202085. ba atAllPut: 99. 1 to: 20 do: [ :i | ba at: i put: (#[80 75 3 4 10 7 7 7 7 7 125 83 67 73 7 7 7 7 7 7] at: i) ]. inputStream := ba readStream. bufferSize := 16384. species := ByteArray. buffer := species new: bufferSize. totalRead := 0. outputStream := nil. [ inputStream atEnd ] whileFalse: [ | readCount | readCount := inputStream readInto: buffer startingAt: 1 count: bufferSize. totalRead = 0 ifTrue: [ byte1 := buffer first. ]. totalRead := totalRead + readCount. outputStream ifNil: [ inputStream atEnd ifTrue: [ ^ buffer copyFrom: 1 to: readCount ] ifFalse: [ outputStream := (species new: bufferSize) writeStream ] ]. outputStream next: readCount putAll: buffer startingAt: 1. byte1 = outputStream contents first ifFalse: [ self halt ]. ]. answer := outputStream ifNil: [ species new ] ifNotNil: [ outputStream contents ]. byte1 = answer first ifFalse: [ self halt ]. ^answer *suspicions* This issue appeared with Pharo 6. Some people suggested that it could be a vm issue, and to try my little scenario with the last available vm. I am not sure where to find the last available vm. I did the test using these elements: https://files.pharo.org/image/60/latest.zip https://files.pharo.org/get-files/70/pharo-mac-latest.zip/ <https://files.pharo.org/get-files/70/> The issue is still present -- Cyrille Delaunay

Jan. 18, 2018

Re: [Pharo-dev] [ANN] Pharo TechTalk Dates

by Marcus Denker

> On 18 Jan 2018, at 15:35, Alistair Grant <akgrant0710(a)gmail.com> wrote: > > Hi Marcus, > > Suggested topic: Contributing to Pharo7. :-) Indeed! The Feb 15 Date seems good for that. Marcus

Jan. 18, 2018

Re: [Pharo-dev] [ANN] Pharo TechTalk Dates

by Alistair Grant

Hi Marcus, Suggested topic: Contributing to Pharo7. :-) Thanks! Alistair On 18 January 2018 at 14:52, Marcus Denker <marcus.denker(a)inria.fr> wrote: > Hi, > > Here are the next dates for the Pharo Techtalks. > (for recording of the past ones, see: http://pharo.org/TechTalk ) > > > Jan 30: Pharo TechTalk: Genetic Algorithms > https://association.pharo.org/event-2757884 > > For the others we have no topic yet, but dates are pre-fixed to: > > Feb 15 > https://association.pharo.org/event-2797065 > > March 22 > https://association.pharo.org/event-2797067 > > April 12 > https://association.pharo.org/event-2797068 > > May 17 > https://association.pharo.org/event-2797069 > > June 14 > https://association.pharo.org/event-2797070 > > > - If you have ideas for topics, please tell us! > - With no topic, we will use this slot for a general free discussion. > - If you want to do a TechTalk about a topic but no date is good, we can > change the date! > > Marcus >

Jan. 18, 2018

[ANN] Pharo TechTalk Dates

by Marcus Denker

Hi, Here are the next dates for the Pharo Techtalks. (for recording of the past ones, see: http://pharo.org/TechTalk ) Jan 30: Pharo TechTalk: Genetic Algorithms https://association.pharo.org/event-2757884 For the others we have no topic yet, but dates are pre-fixed to: Feb 15 https://association.pharo.org/event-2797065 March 22 https://association.pharo.org/event-2797067 April 12 https://association.pharo.org/event-2797068 May 17 https://association.pharo.org/event-2797069 June 14 https://association.pharo.org/event-2797070 - If you have ideas for topics, please tell us! - With no topic, we will use this slot for a general free discussion. - If you want to do a TechTalk about a topic but no date is good, we can change the date! Marcus

Jan. 18, 2018

Re: [Pharo-dev] [ANN] Updating Consultants Listing

by Marcus Denker

This is the next step. The association database has an API and we can auto-generate the list. I wanted to not enforce membership manualy before this this is implemented. It is important to bound it to something so it does not end up like the âcompanies using Smalltalkâ lis of ESUG, where entries are added but old ones *never* removedâ¦ as when you stop using something you tend to not ask to be removed. I am sure some of the entries of the consultants list are stale already. With binding it to the association, people that leave the community will stop membership and thus the list will be up to date automatically. And it is one the things that make sense to offer as part of a membership. Marcus > On 18 Jan 2018, at 09:20, Serge Stinckwich <serge.stinckwich(a)gmail.com> wrote: > > Consultants listed on this board are not gold association member like said here ? > https://association.pharo.org/Benefits <https://association.pharo.org/Benefits> > > On Wed, Jan 17, 2018 at 5:27 PM, Marcus Denker <marcus.denker(a)inria.fr <mailto:marcus.denker@inria.fr>> wrote: > Hi, > > We have http://consultants.pharo.org <http://consultants.pharo.org/> > > I want to change it to > - not be a forward to files.pharo.org <http://files.pharo.org/> > - be auto-generated from the https://association.pharo.org <https://association.pharo.org/> > > > But we should update it already before that is finished. So: > > If you want to be listed, please send your infos in the form: > > PharoConsultant { > #name : Your name', > #email : your(a)email.com <mailto:your@email.com>', > #website : 'http://your-website.com <http://your-website.com/>', > #id : 'yourname (currently not used for anything)', > #location : 'City, Country of your business', > #languages : 'what languages do you speak', > #industryExperienceSince : 1994, > #pharoExperienceSince : 2008, > #areasOfExpertise : 'what are your areas of expertise. E.g. business apllications, user interface, legacy, ...', > #smalltalkExperienceSince : 2002 > } > > (or open a pull request at: https://github.com/pharo-project/pharo-project-consultants/ <https://github.com/pharo-project/pharo-project-consultants/>) > > Marcus > > > > -- > Serge Stinckwich > UMI UMMISCO 209 (IRD/UPMC/UY1) > "Programs must be written for people to read, and only incidentally for machines to execute." > http://www.doesnotunderstand.org/ <http://www.doesnotunderstand.org/>

Jan. 18, 2018

Re: [Pharo-dev] [ANN] Updating Consultants Listing

by Sven Van Caekenberghe

> On 18 Jan 2018, at 09:20, Serge Stinckwich <serge.stinckwich(a)gmail.com> wrote: > > Consultants listed on this board are not gold association member like said here ? > https://association.pharo.org/Benefits We've never been strict on this, but yes, the idea is that anyone who wants to be listed as 'Pharo Consultant' should either be an Association Gold member or a Consortium member. I think that is the least we can ask for. After all, this is publicity for a commercial activity. > On Wed, Jan 17, 2018 at 5:27 PM, Marcus Denker <marcus.denker(a)inria.fr> wrote: > Hi, > > We have http://consultants.pharo.org > > I want to change it to > - not be a forward to files.pharo.org > - be auto-generated from the https://association.pharo.org > > > But we should update it already before that is finished. So: > > If you want to be listed, please send your infos in the form: > > PharoConsultant { > #name : Your name', > #email : your(a)email.com', > #website : 'http://your-website.com', > #id : 'yourname (currently not used for anything)', > #location : 'City, Country of your business', > #languages : 'what languages do you speak', > #industryExperienceSince : 1994, > #pharoExperienceSince : 2008, > #areasOfExpertise : 'what are your areas of expertise. E.g. business apllications, user interface, legacy, ...', > #smalltalkExperienceSince : 2002 > } > > (or open a pull request at: https://github.com/pharo-project/pharo-project-consultants/) > > Marcus > > > > -- > Serge Stinckwich > UMI UMMISCO 209 (IRD/UPMC/UY1) > "Programs must be written for people to read, and only incidentally for machines to execute." > http://www.doesnotunderstand.org/

Jan. 18, 2018

Re: [Pharo-dev] [ANN] Updating Consultants Listing

by Serge Stinckwich

Consultants listed on this board are not gold association member like said here ? https://association.pharo.org/Benefits On Wed, Jan 17, 2018 at 5:27 PM, Marcus Denker <marcus.denker(a)inria.fr> wrote: > Hi, > > We have http://consultants.pharo.org > > I want to change it to > - not be a forward to files.pharo.org > - be auto-generated from the https://association.pharo.org > > > But we should update it already before that is finished. So: > > If you want to be listed, please send your infos in the form: > > PharoConsultant { > #name : Your name', > #email : your(a)email.com <your(a)email.com>', > #website : 'http://your-website.com', > #id : 'yourname (currently not used for anything)', > #location : 'City, Country of your business', > #languages : 'what languages do you speak', > #industryExperienceSince : 1994, > #pharoExperienceSince : 2008, > #areasOfExpertise : 'what are your areas of expertise. E.g. business > apllications, user interface, legacy, ...', > #smalltalkExperienceSince : 2002 > } > > (or open a pull request at: https://github.com/pharo- > project/pharo-project-consultants/) > > Marcus > -- Serge Stinckwich UMI UMMISCO 209 (IRD/UPMC/UY1) "Programs must be written for people to read, and only incidentally for machines to execute."http://www.doesnotunderstand.org/

Jan. 18, 2018

Re: [Pharo-dev] [Pharo-users] [Vm-dev] Running headless on Windows

by Nicolai Hess

2017-12-29 16:53 GMT+01:00 Denis Kudriashov <dionisiydk(a)gmail.com>: > 2017-12-29 16:13 GMT+01:00 Andrei Stebakov <lispercat(a)gmail.com>: > >> Nicolai, the maximize/non-maximize trick worked! Thanks! I wonder if it's >> an easy fix to put in Pharo. >> > > So it means that something in image is not initialised. It can be another > bug of wrong startup order > Maybe a problem on the image and the vm side. Even in headless mode, starting pharo creates a window. Even if it is hidden, it has some size. Quit and Saving an image will write the current width/height into the image file. Starting the vm will create a window and set the size of the window to the last size. The window is always created in normal (not-maximized) mode and the available size is a little bit smaller than for a maximized window. Now, the image checks for a change of the size of the current DisplayScreen instance and the actual screen size. If this is different (as in this case) a new DisplayScreen is initialized which will call a full screen update (ioForceDisplayUpdate). And this method will show a hidden (headless) image. > > >> >> On Fri, Dec 29, 2017 at 6:22 AM, phil(a)highoctane.be <phil(a)highoctane.be> >> wrote: >> >>> I am using nssm because the service option is broken. >>> >>> The code seems to still be in the image but disabled (there are quite a >>> few things like that actually). >>> >>> Phil >>> >>> >>> On Fri, Dec 29, 2017 at 11:59 AM, Torsten Bergmann <astares(a)gmx.de> >>> wrote: >>> >>>> >>>> Hi, (cross posting vm-dev) >>>> >>>> nssm is nice - but requires additional tools. >>>> >>>> Since the days of Squeak the windows VM had the >>>> >>>> -service "ServiceName" >>>> >>>> option and one was able to run Squeak as a windows service out of the >>>> box. >>>> >>>> See http://wiki.squeak.org/squeak/105 for details. >>>> >>>> This option allows to register/deregister with the windows service >>>> manager and run >>>> a headless image. >>>> >>>> I run a Squeak Wiki (Swiki/Comanche) since years with this and it is >>>> very nice and stable. >>>> >>>> Unfortunately this is broken in recent Pharo VMs and so far Esteban or >>>> others did not >>>> have the time to look into this issue. Would be really nice if this >>>> option could >>>> be recovered in 2018. So one could easily deploy and run Seaside or >>>> Teapot/Tealight >>>> or Zinc/WebClient based web services on Windows. >>>> >>>> If we want to deploy Smalltalk based web applications or services on >>>> Windows we >>>> should support that. It will keep Windows administrators happy and we >>>> would integrate with >>>> the whole ecosystem (for instance you can start/stop a service using >>>> Windows scripting for >>>> doing backups, etc.) right out of the box. >>>> >>>> Bye >>>> T. >>>> >>>> >>>> >>>> Gesendet: Freitag, 29. Dezember 2017 um 11:36 Uhr >>>> Von: "phil(a)highoctane.be" <phil(a)highoctane.be> >>>> An: "Any question about pharo is welcome" <pharo-users(a)lists.pharo.org> >>>> Betreff: Re: [Pharo-users] Running headless on Windows >>>> >>>> If you want to run Pharo as a service, I have found nssm to be working >>>> well. >>>> https://nssm.cc >>>> >>>> Phil >>>> >>>> On Dec 29, 2017 09:25, "Nicolai Hess" <nicolaihess(a)gmail.com[mailto: >>>> nicolaihess(a)gmail.com]> wrote: >>>> >>>> >>>> 2017-12-29 3:07 GMT+01:00 Andrei Stebakov <lispercat(a)gmail.com[mailto: >>>> lispercat(a)gmail.com]>: >>>> Pierce, I tried all of those "no display" options, the result is the >>>> same >>>> >>>> >>>> On Dec 28, 2017 8:37 PM, "Pierce Ng" <pierce(a)samadhiweb.com[mailto: >>>> pierce(a)samadhiweb.com]> wrote:On Wed, Dec 27, 2017 at 04:58:39PM >>>> +0100, Cyril Ferlicot D. wrote: >>>> > On 12/27/2017 04:39 PM, Andrei Stebakov wrote: >>>> > > When I run Pharo 6.1 with -- headless option on Windows, it >>>> executes the >>>> > > eval command as expected but during the execution (which lasts 4 >>>> sec) it >>>> > > opens the Pharo GUI. >>>> > > Is it expected? I thought headless means that the whole execution >>>> would >>>> > > happen in the background >>>> > >>>> > I think that currently Pharo does not have a "real" headless. But I >>>> > heard there was work on that part for Pharo 7. >>>> >>>> I know OP is talking about Windows... I've been running server >>>> applications on >>>> Linux without X11 with -vm-display-null and in-image RFBServer for >>>> access to >>>> Pharo over VNC. This works very well for me. >>>> >>>> I believe "real" headless means GUI is not run at all and therefore >>>> does not >>>> consume CPU cycles, which is very welcome. Meanwhile, maybe >>>> -vm-display-null >>>> works on Windows for scripting purposes? >>>> >>>> Pierce >>>> >>>> >>>> >>>> Hi Andrei, >>>> >>>> can you try this: >>>> >>>> Open Pharo normal (no headless option). >>>> Change the window size to "not-maximized" (eve if it is actually not >>>> maximized, maximize it ones and change it back to "not-maximized") >>>> Save and quit the image. >>>> >>>> After that, a call like >>>> >>>> pharo --headless pharo.image eval "DateAndTime now" >>>> will write the output to the stdout file, without opening a window. >>>> >>>> >>>> >>>> >>>> >>>> >>> >>> >> >

Jan. 18, 2018