- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] ZnBufferedReadStream and #upToAll:

by Eric Gade

Hi Sven, I am really curious why you need it ? > This came up for me when I was trying to parse out pieces of a PDF file. As you likely know, the PDF format has both text and binary information encoded within it. I had used #upToAll: in the past to find sequences of "magic bytes" that don't occur in the middle of a file. It seems that the buffered read stream is what you get if you send #binaryReadStream to a FileReference. But you're right â I could just convert streams and do it that way (if you have other techniques you use, please send along). #upToAll: would definitely be complicated to implement in the buffered version! On Mon, Mar 18, 2019 at 5:11 AM Stephan Eggermont <stephan(a)stack.nl> wrote: > ducasse <stepharo(a)netcourrier.com> wrote: > > > > I imagine that sven did not add it because on infinite stream it does > not make sense. > > Now it would be good to see how we can have useful extensions. But I let > this to sven. > > That sounds like something that would be useful to make explicit: > isInfinite, with blocking, returning nil, returning null objects, or > returning errors as possible expected behaviors? > > Stephan > > > > > -- Eric

March 18, 2019

Re: [Pharo-dev] Weird SUnit/TestRunner behavior

by ducasse

You can add a ticket in DrTests in JulienDelplanque repo on github. https://github.com/juliendelplanque/DrTests <https://github.com/juliendelplanque/DrTests> Stef > On 18 Mar 2019, at 13:35, Attila Magyar <m.magyar3(a)gmail.com> wrote: > > Hi, > > This was originally reported as a BabyMock bug but it looks like it effects > normal test cases as well. > > Let's say I have a test like this: > > MyTest>>initialize > super initialize. > s := OrderedCollection new. "note that this is initialized here not in > the setUp as we normally do" > > MyTest>>testWhatever > s add: 42. > 1 / 0. > > Open the Test Runner tool, run the test, it'll fail as expected. Now click > on the failed test (in the test runner window) and the debugger will popup > saying that #add: was sent to nil. Instance variables are cleared out after > a test run but initialize is not called before running it again. Is this > expected? The same doesn't cause any problems when I run it from the System > Browser. > > > > > -- > Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html >

March 18, 2019

Re: [Pharo-dev] Weird SUnit/TestRunner behavior

by ducasse

Thanks for the report. We are working on SUnit improvements. Stef > On 18 Mar 2019, at 13:35, Attila Magyar <m.magyar3(a)gmail.com> wrote: > > Hi, > > This was originally reported as a BabyMock bug but it looks like it effects > normal test cases as well. > > Let's say I have a test like this: > > MyTest>>initialize > super initialize. > s := OrderedCollection new. "note that this is initialized here not in > the setUp as we normally do" > > MyTest>>testWhatever > s add: 42. > 1 / 0. > > Open the Test Runner tool, run the test, it'll fail as expected. Now click > on the failed test (in the test runner window) and the debugger will popup > saying that #add: was sent to nil. Instance variables are cleared out after > a test run but initialize is not called before running it again. Is this > expected? The same doesn't cause any problems when I run it from the System > Browser. > > > > > -- > Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html >

March 18, 2019

Weird SUnit/TestRunner behavior

by Attila Magyar

Hi, This was originally reported as a BabyMock bug but it looks like it effects normal test cases as well. Let's say I have a test like this: MyTest>>initialize super initialize. s := OrderedCollection new. "note that this is initialized here not in the setUp as we normally do" MyTest>>testWhatever s add: 42. 1 / 0. Open the Test Runner tool, run the test, it'll fail as expected. Now click on the failed test (in the test runner window) and the debugger will popup saying that #add: was sent to nil. Instance variables are cleared out after a test run but initialize is not called before running it again. Is this expected? The same doesn't cause any problems when I run it from the System Browser. -- Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html

March 18, 2019

Re: [Pharo-dev] Issue Tracker: enabled Projects (Boards)

by Marcus Denker

> On 18 Mar 2019, at 13:08, Ben Coman <btc(a)openinworld.com> wrote: > > How are issue priorities being assigned? Perhaps there could be a High Priority board? > cheers -ben Yes, that might be a good idea. We did not use priorities that much in the old issue tracker which means that a very simple scheme (like a board) should work, I think. > Poking around the web bumped into a recommendation for this... > https://www.zenhub.com/blog/open-source/ <https://www.zenhub.com/blog/open-source/> We tried to use Trello in the pastâ¦ with mixed success. What I like with the GitHub board is that they are right there, no need to have yet another system, yet another accountâ¦ But it would be definitely interesting to play with it. Marcus

March 18, 2019

Re: [Pharo-dev] Issue Tracker: enabled Projects (Boards)

by Ben Coman

Poking around the web bumped into a recommendation for this... https://www.zenhub.com/blog/open-source/ cheers -ben On Mon, 18 Mar 2019 at 20:08, Ben Coman <btc(a)openinworld.com> wrote: > How are issue priorities being assigned? Perhaps there could be a High > Priority board? > cheers -ben > > On Mon, 18 Mar 2019 at 15:28, Marcus Denker <marcus.denker(a)inria.fr> > wrote: > >> Hi, >> >> We enabled the GitHub âProjectsâ feature for the pharo repo: >> >> https://github.com/pharo-project/pharo/projects >> >> >> The idea is that one can add as many âKanbanâ style boards as one wants. >> issues and pull requests can be added, as well as simple cards that are >> not yet issues. >> >> This is quite nice as an issue tracker gets very confusing and >> overwhelming as soon as there >> are >500 issues. >> >> With these boards, we can create âviewsâ on this sea of issues. >> >> I created for now: >> >> -> some board related to specific parts of the system (e.g. >> Traits or Reflectivity) >> example: >> https://github.com/pharo-project/pharo/projects/11 >> -> "Pharo7 Backportingâ >> >> https://github.com/pharo-project/pharo/projects/12 >> -> "Simple Issues for Beginnersâ >> >> https://github.com/pharo-project/pharo/projects/14 >> Here the feature to be able to put things that are not yet >> issue tracker entries seems very useful >> >> >> I think this can be quite niceâ¦ we should add more Projects as soon as we >> find that they make sense >> and should move issues there. >> >> Marcus >> >

March 18, 2019

Re: [Pharo-dev] Issue Tracker: enabled Projects (Boards)

by Ben Coman

How are issue priorities being assigned? Perhaps there could be a High Priority board? cheers -ben On Mon, 18 Mar 2019 at 15:28, Marcus Denker <marcus.denker(a)inria.fr> wrote: > Hi, > > We enabled the GitHub âProjectsâ feature for the pharo repo: > > https://github.com/pharo-project/pharo/projects > > > The idea is that one can add as many âKanbanâ style boards as one wants. > issues and pull requests can be added, as well as simple cards that are > not yet issues. > > This is quite nice as an issue tracker gets very confusing and > overwhelming as soon as there > are >500 issues. > > With these boards, we can create âviewsâ on this sea of issues. > > I created for now: > > -> some board related to specific parts of the system (e.g. Traits > or Reflectivity) > example: > https://github.com/pharo-project/pharo/projects/11 > -> "Pharo7 Backportingâ > https://github.com/pharo-project/pharo/projects/12 > -> "Simple Issues for Beginnersâ > > https://github.com/pharo-project/pharo/projects/14 > Here the feature to be able to put things that are not yet > issue tracker entries seems very useful > > > I think this can be quite niceâ¦ we should add more Projects as soon as we > find that they make sense > and should move issues there. > > Marcus >

March 18, 2019

[Pharo 8.0] Build #147: 2858-GRVariableAssignedLiteralRule-raises-exception-on-slots-not-inherited-from-IndexedSlot

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

There is a new Pharo build available! The status of the build #147 was: SUCCESS. The Pull Request #2859 was integrated: "2858-GRVariableAssignedLiteralRule-raises-exception-on-slots-not-inherited-from-IndexedSlot" Pull request url: https://github.com/pharo-project/pharo/pull/2859 Issue Url: https://pharo.fogbugz.com/f/cases/2858 Build Url: https://ci.inria.fr/pharo-ci-jenkins2/job/Test%20pending%20pull%20request%2…

March 18, 2019

Re: [Pharo-dev] ZnBufferedReadStream and #upToAll:

by Stephan Eggermont

ducasse <stepharo(a)netcourrier.com> wrote: > > I imagine that sven did not add it because on infinite stream it does not make sense. > Now it would be good to see how we can have useful extensions. But I let this to sven. That sounds like something that would be useful to make explicit: isInfinite, with blocking, returning nil, returning null objects, or returning errors as possible expected behaviors? Stephan

March 18, 2019

[Issue Trackker][Help Needed]: Move issues from Fogbugz to GitHub

by Marcus Denker

Hi, We should all look at the old issues: https://pharo.fogbugz.com/f/filters/57/All-newest-first <https://pharo.fogbugz.com/f/filters/57/All-newest-first> and move them to the new one: https://github.com/pharo-project/pharo/issues instead of moving them automatically, we should take the chance to clean up. Please check, first for the issues that *you* added: -> is it still relevant? ->if yes: add a new issue on GitHub ->close this issue, there is now an explicit âmoved to GitHubâ state. Marcus

March 18, 2019