- Pharo-users - lists.pharo.org

Re: [Pharo-users] I think I've discovered an error in the later v9 builds

by Russ Whaley

Thanks Ben, I'll head over to the link tomorrow. I have done a bit of testing and have been able to isolate in which build the error(s) were introduced. I have yet to follow through the debugger and determine what's going wrong. It looks like something was (attempted to be) fixed with the sorting of the columns that jacked up the clicks for the transmitTo: transform: ... but that's just a guess due to the number of errors around sorting and transmitTo:/transform: I was able to use a Smalltalk method to get what I needed on which build I was using - good to know about the System Reporter as well. Thanks! Russ On Tue, Jul 7, 2020 at 2:18 PM Ben Coman <btc(a)openinworld.com> wrote: > > > On Thu, 2 Jul 2020 at 06:20, Russ Whaley <whaley.russ(a)gmail.com> wrote: > >> I'd be happy to, but um... I don't know how/where (color me >> embarrassed...). Can you point me in the right direction? I've not >> submitted a bug report before. >> > > I would guess Stef means... https://github.com/pharo-spec/Spec/issues > > > >> I've created a sample Class, App, & Presenter that demonstrates the error >> consistently. I was kindof hoping when I created this example I would find >> it was something in my code... I'll attach the fileout here but will also >> include it in the bug report. Also attached are the screenshots before and >> after I clicked on the first row. >> >> Is there a way to tell the build number of an image I'm using? I'd like >> to go back to a fresh image of the image I'm using... it has inflated to >> over 350MB and I'd like to start fresh with an image that doesn't have this >> defect. If I can get hold of the build of the image I'm using, that would >> be great. >> > > You are able to get build info using... World > System > System Reporter > > > >> >> Thanks, >> Russ >> >> >> On Wed, Jul 1, 2020 at 1:42 PM StÃ©phane Ducasse < >> stephane.ducasse(a)inria.fr> wrote: >> >>> Thanks can you enter a bug entry in the spec project? >>> >>> S. >>> >>> On 1 Jul 2020, at 16:58, Russ Whaley <whaley.russ(a)gmail.com> wrote: >>> >>> (Overall, this error does not occur in v8 - even the latest >>> snapshot.1140. It did not exist in the v9 image from February - I don't >>> know how to tell what build it is. But the latest Official Distribution >>> for v9 and the latest snapshot.840 - the following error occurs:). >>> >>> This error appears to be around the transmitTo: within >>> SpPresenterWithModel>>connectPresenters. I haven't been able to (yet) >>> trace why, but the debug message is in the 2nd 'transform:' below -- >>> erroring saying that 'each' is nil - and doesn't understand the #method2 >>> message. >>> >>> Here is the scenario: >>> >>> (aSpTablePresenter(1) transmitTo: aSpTablePresenter(2)) >>> >>> transform: [ :each | ((each #method asOrderedCollection ) sorted: #title >>> ascending ) ]. >>> >>> >>> "transmit aSpTablePresenter(2) to aSpTablePresenter(3)" >>> (aSpTablePresenter(2) transmitTo: aSpTablePresenter(3)) >>> >>> transform: [ :each | ((*each #method2* asOrderedCollection) sorted: >>> #number ascending )]. >>> >>> >>> The UI populates just fine - when I click a row in the first >>> aSpTablePresenter(1) - it fills the 2nd aSpTablePresenter(2), but it looks >>> like the code above attempts to do the 2nd transmitTo: to populate >>> aSpTablePresenter(3) and is trying to do so without data from >>> aSpTablePresenter(2) - there could be a number of reasons for this. >>> >>> Behavior-wise, I would prefer that SpTablePresenters default to a first >>> row selected and populate (transmitTo:) to each of their SpTablePresenters >>> in kind (defaulting to first row, then transmitTo: the next >>> tablePresenter). >>> >>> Through the Inspector, all three SpTablePresenters have their lists >>> populated - and the UI shows these lists - even after punching through >>> error. >>> >>> Another observable - when I click on column headers to sort, the >>> transmitTo:'s get called again and also error out - even the first >>> transmitTo:... could be one simple change will correct all these anomalies. >>> >>> I will try and mock-up a simpler version to share. Please let me know >>> if you have any questions or items I should specifically include. >>> >>> Thanks! >>> Russ >>> >>> -- >>> Russ Whaley >>> whaley.russ(a)gmail.com >>> >>> >>> -------------------------------------------- >>> StÃ©phane Ducasse >>> http://stephane.ducasse.free.fr / http://www.pharo.org >>> 03 59 35 87 52 >>> Assistant: Aurore Dalle >>> FAX 03 59 57 78 50 >>> TEL 03 59 35 86 16 >>> S. Ducasse - Inria >>> 40, avenue Halley, >>> Parc Scientifique de la Haute Borne, BÃ¢t.A, Park Plaza >>> Villeneuve d'Ascq 59650 >>> France >>> >>> >> >> -- >> Russ Whaley >> whaley.russ(a)gmail.com >> > -- Russ Whaley whaley.russ(a)gmail.com

July 8, 2020

glamorous toolkit & pharo

by Tudor Girba

Hi, As Glamorous Toolkit gets closer to being released, we get quite a number of questions on various channels about its relationship with Pharo. Glamorous Toolkit is built with Pharo. It is unlikely that we would have been able to produce it in any other language within the constraints we faced. At the same time, Glamorous Toolkit is a separate project produced by feenk with a distinct goal and its own realization. Here is a short overview of what we mean by it: https://blog.feenk.com/glamorous-toolkit-and-pharo-5aufgcequ38az2s0dj0t1nu0… Please do let us know if you have concerns or questions. Cheers, Doru -- feenk.com [fiËÅk] verb feel and think concomitantly.

July 7, 2020

Re: [Pharo-users] I think I've discovered an error in the later v9 builds

by Ben Coman

On Thu, 2 Jul 2020 at 06:20, Russ Whaley <whaley.russ(a)gmail.com> wrote: > I'd be happy to, but um... I don't know how/where (color me > embarrassed...). Can you point me in the right direction? I've not > submitted a bug report before. > I would guess Stef means... https://github.com/pharo-spec/Spec/issues > I've created a sample Class, App, & Presenter that demonstrates the error > consistently. I was kindof hoping when I created this example I would find > it was something in my code... I'll attach the fileout here but will also > include it in the bug report. Also attached are the screenshots before and > after I clicked on the first row. > > Is there a way to tell the build number of an image I'm using? I'd like > to go back to a fresh image of the image I'm using... it has inflated to > over 350MB and I'd like to start fresh with an image that doesn't have this > defect. If I can get hold of the build of the image I'm using, that would > be great. > You are able to get build info using... World > System > System Reporter > > Thanks, > Russ > > > On Wed, Jul 1, 2020 at 1:42 PM StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> > wrote: > >> Thanks can you enter a bug entry in the spec project? >> >> S. >> >> On 1 Jul 2020, at 16:58, Russ Whaley <whaley.russ(a)gmail.com> wrote: >> >> (Overall, this error does not occur in v8 - even the latest >> snapshot.1140. It did not exist in the v9 image from February - I don't >> know how to tell what build it is. But the latest Official Distribution >> for v9 and the latest snapshot.840 - the following error occurs:). >> >> This error appears to be around the transmitTo: within >> SpPresenterWithModel>>connectPresenters. I haven't been able to (yet) >> trace why, but the debug message is in the 2nd 'transform:' below -- >> erroring saying that 'each' is nil - and doesn't understand the #method2 >> message. >> >> Here is the scenario: >> >> (aSpTablePresenter(1) transmitTo: aSpTablePresenter(2)) >> >> transform: [ :each | ((each #method asOrderedCollection ) sorted: #title >> ascending ) ]. >> >> >> "transmit aSpTablePresenter(2) to aSpTablePresenter(3)" >> (aSpTablePresenter(2) transmitTo: aSpTablePresenter(3)) >> >> transform: [ :each | ((*each #method2* asOrderedCollection) sorted: >> #number ascending )]. >> >> >> The UI populates just fine - when I click a row in the first >> aSpTablePresenter(1) - it fills the 2nd aSpTablePresenter(2), but it looks >> like the code above attempts to do the 2nd transmitTo: to populate >> aSpTablePresenter(3) and is trying to do so without data from >> aSpTablePresenter(2) - there could be a number of reasons for this. >> >> Behavior-wise, I would prefer that SpTablePresenters default to a first >> row selected and populate (transmitTo:) to each of their SpTablePresenters >> in kind (defaulting to first row, then transmitTo: the next >> tablePresenter). >> >> Through the Inspector, all three SpTablePresenters have their lists >> populated - and the UI shows these lists - even after punching through >> error. >> >> Another observable - when I click on column headers to sort, the >> transmitTo:'s get called again and also error out - even the first >> transmitTo:... could be one simple change will correct all these anomalies. >> >> I will try and mock-up a simpler version to share. Please let me know if >> you have any questions or items I should specifically include. >> >> Thanks! >> Russ >> >> -- >> Russ Whaley >> whaley.russ(a)gmail.com >> >> >> -------------------------------------------- >> StÃ©phane Ducasse >> http://stephane.ducasse.free.fr / http://www.pharo.org >> 03 59 35 87 52 >> Assistant: Aurore Dalle >> FAX 03 59 57 78 50 >> TEL 03 59 35 86 16 >> S. Ducasse - Inria >> 40, avenue Halley, >> Parc Scientifique de la Haute Borne, BÃ¢t.A, Park Plaza >> Villeneuve d'Ascq 59650 >> France >> >> > > -- > Russ Whaley > whaley.russ(a)gmail.com >

July 7, 2020

Re: [Pharo-users] How to set path as a variable

by Ben Coman

That is useful to know the PATH variable can be updated for current process. Nice blog writeup. Thanks Chris. cheers -ben On Sun, 28 Jun 2020 at 23:49, Christopher Fuhrman < christopher.fuhrman(a)etsmtl.ca> wrote: > Then you can add your directory to it (note that I put a semicolon for >> path separator in Windows): >> >> modifiedPath := 'D:\DEV_FreeCAD\build\bin\;' + path. > > > My apologies (I have been coding too much JavaScript lately) - this should > have been: > > modifiedPath := 'D:\DEV_FreeCAD\build\bin\;' , path. > > > Cheers, > > > On Sun, 28 Jun 2020 at 11:16, Christopher Fuhrman < > christopher.fuhrman(a)etsmtl.ca> wrote: > >> Hello, >> >> Why not use the PATH environment variable in Windows to do what you want? >> I deal with setting variables used with LibC in my blog entry at >> https://fuhrmanator.github.io/2019/03/16/LibC-Pharo-experiments.html >> >> You can get PATH by using: >> >> path := OSEnvironment current getEnv: 'PATH'. >> >> Then you can add your directory to it (note that I put a semicolon for >> path separator in Windows): >> >> modifiedPath := 'D:\DEV_FreeCAD\build\bin\;' + path. >> >> Then you have to set the variable in the system: >> >> result := OSEnvironment current setEnv: 'PATH' value: modifiedPath. >> >> You should probably get (again) the variable PATH (as above) to make sure >> the path was set correctly. >> >> Then just do: >> >> result := LibC runCommand: 'makebox.step'. >> >> Let us know if it works for you. >> >> Cheers! >> >> On Sun, 28 Jun 2020 at 09:03, shawon58 <shawonhoque58(a)gmail.com> wrote: >> >>> In pharo class side , i am creating class side method like as >>> /*makebox >>> LibC system: 'D:\DEV_FreeCAD\build\bin\makebox.step'*/ >>> SO i want to set /D:\DEV_FreeCAD\build\bin\ / as a variable like path >>> than i >>> can write like as >>> *LibC system: 'path\makebox.step'* >>> >>> how to do that, if anyone have idea please share the idea with me. >>> >>> Thanks for your help >>> >>> >>> >>> >>> -- >>> Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html >>> >>> >> >> -- >> Christopher Fuhrman, P.Eng., PhD >> >> *Professeur au DÃ©partement de gÃ©nie logiciel et des technologies de >> l'informationÃ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* >> > > > -- > Christopher Fuhrman, P.Eng., PhD > > *Professeur au DÃ©partement de gÃ©nie logiciel et des technologies de > l'informationÃ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* >

July 7, 2020

Re: [Pharo-users] Output the method name as a string at runtime

by Ben Coman

Sorry for the slow response. Perhaps you've already worked it out, but anyway a few options... You "could" pass thisContext as a block parameter initialize errorBlock := [ :tPduError :aContext | Error signal:'Method: ' , aContext selector asString , ' with result: ', tPduError item asString ]. pduDestruct result = T_PDU_ERROR PDU_STATUS_NOERROR ifFalse: [ errorBlock value: result value: thisContext ------------------------------------ But rather I suggest a better option is to separate this logic into its own error class... Error subclass: #PduError ... instanceVariables: 'result selector' PduError class >> result: aResult context: aContext ^ self new initializeResult: aResult selector: aContext selector asString PduError >> initializeResult: aResult selector: selectorString result := aResult. selector := selectorString PduEror>>messageText as you like - refer to other implementors for example PduError>>printOn: as you like - refer to other implementors for example pduDestruct | result | result := call ffiPDUDestruct. result = T_PDU_ERROR PDU_STATUS_NOERROR ifFalse: [ (PduError result: aResult context: thisContext) signal ] cheers -ben On Sat, 27 Jun 2020 at 22:56, ASAM <vmax28575(a)gmail.com> wrote: > Hello, > I would like to output the method name as a string in case of an error. > > what I've already done is this: (with thisContext selector asString) > > pduDestruct > | result | > result := call ffiPDUDestruct. > result = T_PDU_ERROR PDU_STATUS_NOERROR > ifFalse: [ Error signal:'Method: ' , thisContext selector asString , ' > with > result: ', result item asString ] > > > but now I use it more often. And wanted to rebuild it like that. > > initialize > errorBlock := [ :tPduError | Error signal:'Method: ' , thisContext > selector > asString , ' with result: ', tPduError item asString ]. > > > pduDestruct > | result | > result := call ffiPDUDestruct. > result = T_PDU_ERROR PDU_STATUS_NOERROR ifFalse: [ errorBlock > value: result > ] > > > but that doesn't work because "this Context selector toString" now returns > 'initialize'. > > Can someone give me a hint how to solve this? > Is "thisContext selector asString" the only way to get the name of the > method at runtime? > > Thanks in advance. >

July 7, 2020

Re: [Pharo-users] Pharo 9 Unicode

by Tomohiro Oda

TomaÅ¾ and Sven, I tested Pharo-9.0.0+build.469.sha.fcf155b2849b5b411091f5a7ea6014bf57ddf402 (64 Bit) that I downloaded by PharoLauncher a few minutes ago. It works fine if the code font and default font are set appropriately. The attached is snapshot of Playground with appearently higher than 255 codepoints. --- tomo [image: Playground.png]

July 7, 2020

Re: [Pharo-users] Pharo 9 Unicode

by Sven Van Caekenberghe

That would be an unacceptable regression. In Pharo-9.0.0+build.441.sha.bb8e0557173ef202e6e8a001d429df8101613878 (64 Bit) it still works: So it might be a very recent problem. > On 7 Jul 2020, at 13:35, TomaÅ¾ Turk <tomaz.turk(a)ef.uni-lj.si> wrote: > > Dear all, > > I noticed that in various Pharo 9.0 builds that I have Unicode characters above 255 are not displayed correctly if displayed by Print It, inspector or otherwise processed by code. They are displayed correctly if typed directly into editor, e.g. Playground. This is a result from Print It: > > <wiykxnxz.png> > > This is from Pharo 8.0: > > <r0dpkbst.png> > > Best wishes, > Tomaz

July 7, 2020

Pharo 9 Unicode

by TomaÅ¾ Turk

Dear all, I noticed that in various Pharo 9.0 builds that I have Unicode characters above 255 are not displayed correctly if displayed by Print It, inspector or otherwise processed by code. They are displayed correctly if typed directly into editor, e.g. Playground. This is a result from Print It: This is from Pharo 8.0: Best wishes, Tomaz

July 7, 2020

[ANN] Stargate v5.1.0 [v5.1.0] released!

by Buenos Aires Smalltalk

July 6, 2020

Re: [Pharo-users] [Esug-list] new Pharo success story :)

by StÃ©phane Ducasse

Hello hennie I do not know but what they are doing is really advanced and most of their work is private for the french gov. And advanced gestures and tactil screens were not available back in 89 :) What would be sad is that it would NOT be done in Pharo but in JS like or Java FX. Donât you think? Of course it can be sad to see things that have been already done, redone. You see Pharo is not a proprietary system so sometimes we are forced to reinvent the wheel but this is an open-source wheel. :) So we get sometimes feedback like it is already available in X or Z, but proprietary code is not available It does not exist except for paying clients. For us we even consider GNU licensed code as forbidden to stay clean. Pharo is following a pure and cristal clear MIT license, it means that people can take the code and do whatever they want, even contribute back or not. Do not hesitate to have fun with us because with Pharo we are really trying to push forward and let people invent what they want and change the world. You can discuss with us on https://discord.gg/QewZMZa <https://discord.gg/QewZMZa> S.

July 6, 2020