Re: [Pharo-users] I think I've discovered an error in the later v9 builds
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 wrote: > > > On Thu, 2 Jul 2020 at 06:20, Russ Whaley 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.duca...@inria.fr> wrote: >> >>> Thanks can you enter a bug entry in the spec project? >>> >>> S. >>> >>> On 1 Jul 2020, at 16:58, Russ Whaley 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.r...@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.r...@gmail.com >> > -- Russ Whaley whaley.r...@gmail.com
[Pharo-users] glamorous toolkit & pharo
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-5aufgcequ38az2s0dj0t1nu0f/ Please do let us know if you have concerns or questions. Cheers, Doru -- feenk.com [fiːŋk] verb feel and think concomitantly.
Re: [Pharo-users] I think I've discovered an error in the later v9 builds
On Thu, 2 Jul 2020 at 06:20, Russ Whaley 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 > wrote: > >> Thanks can you enter a bug entry in the spec project? >> >> S. >> >> On 1 Jul 2020, at 16:58, Russ Whaley 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.r...@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.r...@gmail.com >
Re: [Pharo-users] How to set path as a variable
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.fuhr...@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.fuhr...@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 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* >
Re: [Pharo-users] Output the method name as a string at runtime
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 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. >
Re: [Pharo-users] Pharo 9 Unicode
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]
[Pharo-users] Pharo 9 Unicode
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
