March 2020 - Pharo-users - lists.pharo.org

Re: [Pharo-users] [Lse-pharo4pharo] How to get a list of package versions?

by HernÃ¡n Morales Durand

Hi Stef, Didn't knew this project existed: https://github.com/pharo-pkg Glad to read someone is taking care of it. In the meantime I will explore about file system workaround with diff-like tools. Thank you for your reply. Cheers, HernÃ¡n El jue., 12 mar. 2020 a las 4:25, StÃ©phane Ducasse (< stephane.ducasse(a)inria.fr>) escribiÃ³: > Hi hernan > > I understand exactly your question :) > Because we need to have metadata inside the package. > I hope that the renewed effort around pakbot will address this point. > > On 12 Mar 2020, at 04:22, HernÃ¡n Morales Durand <hernan.morales(a)gmail.com> > wrote: > > Hi there, > > I would like to compare two Pharo deployed images. Specifically, get a > list/tree of the installed packages with their version number each one, so > I can compare if there were updates between both deployments. > > I started by doing > > IceRepository registry collect: #workingCopy > > Then discovered the #commitish, though don't know is there another way? > Cheers, > > HernÃ¡n > > _______________________________________________ > Lse-pharo4pharo mailing list > Lse-pharo4pharo(a)lists.gforge.inria.fr > https://lists.gforge.inria.fr/mailman/listinfo/lse-pharo4pharo > > > -------------------------------------------- > StÃ©phane Ducasse > http://stephane.ducasse.free.fr / http://www.pharo.org > 03 59 35 87 52 > Assistant: Julie Jonas > 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 > >

March 12, 2020

Re: [Pharo-users] Generate class hierarchy from JSON Schema

by eftomi

Esteban, if time permits, could you please describe what situations lead to crashes, and with which images? Thanks, Tomaz -- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html

March 12, 2020

How to get a list of package versions?

by HernÃ¡n Morales Durand

Hi there, I would like to compare two Pharo deployed images. Specifically, get a list/tree of the installed packages with their version number each one, so I can compare if there were updates between both deployments. I started by doing IceRepository registry collect: #workingCopy Then discovered the #commitish, though don't know is there another way? Cheers, HernÃ¡n

March 12, 2020

Re: [Pharo-users] Generate class hierarchy from JSON Schema

by TomaÅ¾ Turk

Thanks for the PR! Maybe something can be done also on the PharoCOM level within calculateMethods and calculateProperties. I didn't experience any crashes, although I developed PharoADO on 32bits in Pharo 7 and Pablo upgraded PharoCOM to 64bit after Pharo 8 was released. Besides, I haven't managed yet to re-check if all the COM instances are properly released after usage. Best wishes Tomaz ------ Original Message ------ From: "Esteban Maringolo" <emaringolo(a)gmail.com> To: "TomaÅ¾ Turk" <tomaz.turk(a)ef.uni-lj.si> Cc: "Any question about pharo is welcome" <pharo-users(a)lists.pharo.org> Sent: 11. 03. 2020 20:35:10 Subject: Re: Re[2]: [Pharo-users] Generate class hierarchy from JSON Schema >Follow up. > >Seems that playing with these COM/ADO objects in the playground messes >with the VM; so I'm getting weird image crashes, where the image closes >without any notice. > >Do you experience the same? > > >Esteban A. Maringolo > > >On Wed, Mar 11, 2020 at 4:11 PM Esteban Maringolo ><emaringolo(a)gmail.com> wrote: >>I did a small change in ADORecordset to have the fields as an instVar >>and also in ADOFields to have each ADOField in an `items` instVar. >>It is still slow compared to an ODBC API, but I got a 20x speedup >>(~1000ms), that is spent mostly on the actual call to the dispatcher >>to fetch each cell value. >> >>I look forward for an ODBC API, but at least to read any other data >>source, this seems to work pretty well. >> >>I already sent a pull-request. >> >>Esteban A. Maringolo >> >> >>On Wed, Mar 11, 2020 at 3:31 PM Esteban Maringolo >><emaringolo(a)gmail.com> wrote: >>> >>>The profiling using the recordset was even worst. I changed the >>>iteration [1] to add everything to a collection, but most of the time >>>is spent in #calculateMethods and #calculateProperties. Which is >>>performed everytime for each ADOField. >>> >>>I wouldn't consider this a stress test, but maybe the methods and >>>properties should be cached, or a different class of dispatcher >>>should be used where the methods and properties are defined ahead of >>>time instead of being discovered when first invoked. >>> >>>Regards, >>> >>> >>>[1] "Modified code" >>>rst := ADORecordset createInstance . >>>rst open: 'SELECT * FROM PLAYER' activeConnection: conn cursorType: 2 >>>lockType: 3 options: -1. >>>results := OrderedCollection new. >>>[rst eof] whileFalse: [ >>> | row | >>> row := Array new: rst fields count. >>> 1 to: row size do: [ :idx | row at: idx put: (rst fields item: idx) >>>value ]. >>> results add: row. >>> rst moveNext >>> ]. >>> >>> >>> >>>Esteban A. Maringolo >>> >>> >>>On Wed, Mar 11, 2020 at 3:02 PM TomaÅ¾ Turk <tomaz.turk(a)ef.uni-lj.si> >>>wrote: >>>>Hi Esteban, >>>> >>>>Thanks for reporting this issue. I haven't made any "stress" tests >>>>yet for ADOClient. Could you please try to use ADORecordset as >>>>described in the readme? There you have a direct access to each >>>>record at a time, and then you can create your own "loop" to process >>>>the query result. In this way you can avoid the loop in >>>>ADOClient>>query: method. >>>> >>>>Best wishes, >>>>Tomaz >>>> >>>>------ Original Message ------ >>>>From: "Esteban Maringolo" <emaringolo(a)gmail.com> >>>>To: "TomaÅ¾ Turk" <tomaz.turk(a)ef.uni-lj.si>; "Any question about >>>>pharo is welcome" <pharo-users(a)lists.pharo.org> >>>>Sent: 11. 03. 2020 18:25:51 >>>>Subject: Re: [Pharo-users] Generate class hierarchy from JSON Schema >>>> >>>>>As an additional reference, I attach the profile tally for the >>>>>query I'm mentioning. >>>>> >>>>>The culprit seems to be the calculation of the ADOField properties >>>>>that might be calculated on every call. >>>>> >>>>>Regards, >>>>> >>>>>Esteban A. Maringolo >>>>> >>>>> >>>>>On Wed, Mar 11, 2020 at 2:13 PM Esteban Maringolo >>>>><emaringolo(a)gmail.com> wrote: >>>>>>Hi, >>>>>> >>>>>>To feed a Pharo app I need to read from an old MDB file, via ODBC. >>>>>> >>>>>>So I tested PharoADO and, after adding a missing Variant Type [1], >>>>>>I got my query working (at least read only). >>>>>> >>>>>>However the time of ADOClient to return a query with 10K rows of 5 >>>>>>columns each is extremely slow (+65000ms) compared, e.g., with >>>>>>Dolphin Smalltalk via ODBC (62ms). >>>>>> >>>>>>The time of the execute call to return is instantaneous, so I >>>>>>think the issue might be in the creation of the result set. >>>>>> >>>>>>Is this a known issue? >>>>>> >>>>>>Should I check something else? >>>>>> >>>>>>Thanks in advance, >>>>>> >>>>>> >>>>>>[1] https://github.com/tesonep/pharo-com/pull/10 >>>>>>Esteban A. Maringolo >>>>>> >>>>>> >>>>>>On Fri, Jan 24, 2020 at 5:59 AM TomaÅ¾ Turk >>>>>><tomaz.turk(a)ef.uni-lj.si> wrote: >>>>>>> >>>>>>>>That would be amazing! >>>>>>>> >>>>>>>>I'm a Mac/Unix guy so I don't have access to the other platforms >>>>>>>>(I suppose I could fire up an AWS Oracle). I can do >>>>>>>>mysql/mariadb, posgresql, and sqlite. >>>>>>>> >>>>>>>>I'm pretty close to pushing my ActiveRecord extensions. I just >>>>>>>>need to get many to many with link tables done and it is good to >>>>>>>>go. I spent a few days "porting" the ruby inflector and its >>>>>>>>tests. >>>>>>>> >>>>>>>>As for database introspection, I am relying on this new method >>>>>>>>and the result set format on DatabasePlatform. >>>>>>>> >>>>>>>>printSqlStatementToListColumnsInTable: aDatabaseTable inSchema: >>>>>>>>schemaString on: aStream >>>>>>>>" Format: >>>>>>>> name | type | length | nullable | >>>>>>>> default_value | pk >>>>>>>>-------------------------+-------------------+--------+----------+-----------------------+---- >>>>>>>> id | character varying | 255 | 0 >>>>>>>>| ''::character varying | 1 >>>>>>>> >>>>>>>> >>>>>>>This is great news about ActiveRecord! >>>>>>> >>>>>>>ADO is, unfortunately, a Windows library, so PharoADO is limited >>>>>>>to Windows. Maybe as a next step we should focus into Garage and >>>>>>>the addition of SQL Server and Oracle support. If I only had time >>>>>>>... >>>>>>> >>>>>>>StÃ©phane, thanks for the support. >>>>>>> >>>>>>>Best wishes, >>>>>>>Tomaz >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>>

March 11, 2020

Re: [Pharo-users] Generate class hierarchy from JSON Schema

by Esteban Maringolo

Follow up. Seems that playing with these COM/ADO objects in the playground messes with the VM; so I'm getting weird image crashes, where the image closes without any notice. Do you experience the same? Esteban A. Maringolo On Wed, Mar 11, 2020 at 4:11 PM Esteban Maringolo <emaringolo(a)gmail.com> wrote: > I did a small change in ADORecordset to have the fields as an instVar and > also in ADOFields to have each ADOField in an `items` instVar. > It is still slow compared to an ODBC API, but I got a 20x speedup > (~1000ms), that is spent mostly on the actual call to the dispatcher to > fetch each cell value. > > I look forward for an ODBC API, but at least to read any other data > source, this seems to work pretty well. > > I already sent a pull-request. > > Esteban A. Maringolo > > > On Wed, Mar 11, 2020 at 3:31 PM Esteban Maringolo <emaringolo(a)gmail.com> > wrote: > >> >> The profiling using the recordset was even worst. I changed the iteration >> [1] to add everything to a collection, but most of the time is spent in >> #calculateMethods and #calculateProperties. Which is performed everytime >> for each ADOField. >> >> I wouldn't consider this a stress test, but maybe the methods and >> properties should be cached, or a different class of dispatcher should be >> used where the methods and properties are defined ahead of time instead of >> being discovered when first invoked. >> >> Regards, >> >> >> [1] "Modified code" >> rst := ADORecordset createInstance . >> rst open: 'SELECT * FROM PLAYER' activeConnection: conn cursorType: 2 >> lockType: 3 options: -1. >> results := OrderedCollection new. >> [rst eof] whileFalse: [ >> | row | >> row := Array new: rst fields count. >> 1 to: row size do: [ :idx | row at: idx put: (rst fields item: idx) >> value ]. >> results add: row. >> rst moveNext >> ]. >> >> >> >> Esteban A. Maringolo >> >> >> On Wed, Mar 11, 2020 at 3:02 PM TomaÅ¾ Turk <tomaz.turk(a)ef.uni-lj.si> >> wrote: >> >>> Hi Esteban, >>> >>> Thanks for reporting this issue. I haven't made any "stress" tests yet >>> for ADOClient. Could you please try to use ADORecordset as described in the >>> readme? There you have a direct access to each record at a time, and then >>> you can create your own "loop" to process the query result. In this way you >>> can avoid the loop in ADOClient>>query: method. >>> >>> Best wishes, >>> Tomaz >>> >>> ------ Original Message ------ >>> From: "Esteban Maringolo" <emaringolo(a)gmail.com> >>> To: "TomaÅ¾ Turk" <tomaz.turk(a)ef.uni-lj.si>; "Any question about pharo >>> is welcome" <pharo-users(a)lists.pharo.org> >>> Sent: 11. 03. 2020 18:25:51 >>> Subject: Re: [Pharo-users] Generate class hierarchy from JSON Schema >>> >>> As an additional reference, I attach the profile tally for the query >>> I'm mentioning. >>> >>> The culprit seems to be the calculation of the ADOField properties that >>> might be calculated on every call. >>> >>> Regards, >>> >>> Esteban A. Maringolo >>> >>> >>> On Wed, Mar 11, 2020 at 2:13 PM Esteban Maringolo <emaringolo(a)gmail.com> >>> wrote: >>> >>>> Hi, >>>> >>>> To feed a Pharo app I need to read from an old MDB file, via ODBC. >>>> >>>> So I tested PharoADO and, after adding a missing Variant Type [1], I >>>> got my query working (at least read only). >>>> >>>> However the time of ADOClient to return a query with 10K rows of 5 >>>> columns each is extremely slow (+65000ms) compared, e.g., with Dolphin >>>> Smalltalk via ODBC (62ms). >>>> >>>> The time of the execute call to return is instantaneous, so I think the >>>> issue might be in the creation of the result set. >>>> >>>> Is this a known issue? >>>> >>>> Should I check something else? >>>> >>>> Thanks in advance, >>>> >>>> >>>> [1] https://github.com/tesonep/pharo-com/pull/10 >>>> Esteban A. Maringolo >>>> >>>> >>>> On Fri, Jan 24, 2020 at 5:59 AM TomaÅ¾ Turk <tomaz.turk(a)ef.uni-lj.si> >>>> wrote: >>>> >>>>> >>>>> That would be amazing! >>>>> >>>>> I'm a Mac/Unix guy so I don't have access to the other platforms (I >>>>> suppose I could fire up an AWS Oracle). I can do mysql/mariadb, posgresql, >>>>> and sqlite. >>>>> >>>>> I'm pretty close to pushing my ActiveRecord extensions. I just need >>>>> to get many to many with link tables done and it is good to go. I spent a >>>>> few days "porting" the ruby inflector and its tests. >>>>> >>>>> As for database introspection, I am relying on this new method and the >>>>> result set format on DatabasePlatform. >>>>> >>>>> printSqlStatementToListColumnsInTable: aDatabaseTable inSchema: >>>>> schemaString on: aStream >>>>> " Format: >>>>> name | type | length | nullable | >>>>> default_value | pk >>>>> >>>>> -------------------------+-------------------+--------+----------+-----------------------+---- >>>>> id | character varying | 255 | 0 | >>>>> ''::character varying | 1 >>>>> >>>>> >>>>> This is great news about ActiveRecord! >>>>> >>>>> ADO is, unfortunately, a Windows library, so PharoADO is limited to >>>>> Windows. Maybe as a next step we should focus into Garage and the addition >>>>> of SQL Server and Oracle support. If I only had time ... >>>>> >>>>> StÃ©phane, thanks for the support. >>>>> >>>>> Best wishes, >>>>> Tomaz >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>>

March 11, 2020

Re: [Pharo-users] Generate class hierarchy from JSON Schema

by Esteban Maringolo

I did a small change in ADORecordset to have the fields as an instVar and also in ADOFields to have each ADOField in an `items` instVar. It is still slow compared to an ODBC API, but I got a 20x speedup (~1000ms), that is spent mostly on the actual call to the dispatcher to fetch each cell value. I look forward for an ODBC API, but at least to read any other data source, this seems to work pretty well. I already sent a pull-request. Esteban A. Maringolo On Wed, Mar 11, 2020 at 3:31 PM Esteban Maringolo <emaringolo(a)gmail.com> wrote: > > The profiling using the recordset was even worst. I changed the iteration > [1] to add everything to a collection, but most of the time is spent in > #calculateMethods and #calculateProperties. Which is performed everytime > for each ADOField. > > I wouldn't consider this a stress test, but maybe the methods and > properties should be cached, or a different class of dispatcher should be > used where the methods and properties are defined ahead of time instead of > being discovered when first invoked. > > Regards, > > > [1] "Modified code" > rst := ADORecordset createInstance . > rst open: 'SELECT * FROM PLAYER' activeConnection: conn cursorType: 2 > lockType: 3 options: -1. > results := OrderedCollection new. > [rst eof] whileFalse: [ > | row | > row := Array new: rst fields count. > 1 to: row size do: [ :idx | row at: idx put: (rst fields item: idx) > value ]. > results add: row. > rst moveNext > ]. > > > > Esteban A. Maringolo > > > On Wed, Mar 11, 2020 at 3:02 PM TomaÅ¾ Turk <tomaz.turk(a)ef.uni-lj.si> > wrote: > >> Hi Esteban, >> >> Thanks for reporting this issue. I haven't made any "stress" tests yet >> for ADOClient. Could you please try to use ADORecordset as described in the >> readme? There you have a direct access to each record at a time, and then >> you can create your own "loop" to process the query result. In this way you >> can avoid the loop in ADOClient>>query: method. >> >> Best wishes, >> Tomaz >> >> ------ Original Message ------ >> From: "Esteban Maringolo" <emaringolo(a)gmail.com> >> To: "TomaÅ¾ Turk" <tomaz.turk(a)ef.uni-lj.si>; "Any question about pharo is >> welcome" <pharo-users(a)lists.pharo.org> >> Sent: 11. 03. 2020 18:25:51 >> Subject: Re: [Pharo-users] Generate class hierarchy from JSON Schema >> >> As an additional reference, I attach the profile tally for the query I'm >> mentioning. >> >> The culprit seems to be the calculation of the ADOField properties that >> might be calculated on every call. >> >> Regards, >> >> Esteban A. Maringolo >> >> >> On Wed, Mar 11, 2020 at 2:13 PM Esteban Maringolo <emaringolo(a)gmail.com> >> wrote: >> >>> Hi, >>> >>> To feed a Pharo app I need to read from an old MDB file, via ODBC. >>> >>> So I tested PharoADO and, after adding a missing Variant Type [1], I got >>> my query working (at least read only). >>> >>> However the time of ADOClient to return a query with 10K rows of 5 >>> columns each is extremely slow (+65000ms) compared, e.g., with Dolphin >>> Smalltalk via ODBC (62ms). >>> >>> The time of the execute call to return is instantaneous, so I think the >>> issue might be in the creation of the result set. >>> >>> Is this a known issue? >>> >>> Should I check something else? >>> >>> Thanks in advance, >>> >>> >>> [1] https://github.com/tesonep/pharo-com/pull/10 >>> Esteban A. Maringolo >>> >>> >>> On Fri, Jan 24, 2020 at 5:59 AM TomaÅ¾ Turk <tomaz.turk(a)ef.uni-lj.si> >>> wrote: >>> >>>> >>>> That would be amazing! >>>> >>>> I'm a Mac/Unix guy so I don't have access to the other platforms (I >>>> suppose I could fire up an AWS Oracle). I can do mysql/mariadb, posgresql, >>>> and sqlite. >>>> >>>> I'm pretty close to pushing my ActiveRecord extensions. I just need to >>>> get many to many with link tables done and it is good to go. I spent a few >>>> days "porting" the ruby inflector and its tests. >>>> >>>> As for database introspection, I am relying on this new method and the >>>> result set format on DatabasePlatform. >>>> >>>> printSqlStatementToListColumnsInTable: aDatabaseTable inSchema: >>>> schemaString on: aStream >>>> " Format: >>>> name | type | length | nullable | >>>> default_value | pk >>>> >>>> -------------------------+-------------------+--------+----------+-----------------------+---- >>>> id | character varying | 255 | 0 | >>>> ''::character varying | 1 >>>> >>>> >>>> This is great news about ActiveRecord! >>>> >>>> ADO is, unfortunately, a Windows library, so PharoADO is limited to >>>> Windows. Maybe as a next step we should focus into Garage and the addition >>>> of SQL Server and Oracle support. If I only had time ... >>>> >>>> StÃ©phane, thanks for the support. >>>> >>>> Best wishes, >>>> Tomaz >>>> >>>> >>>> >>>> >>>> >>>> >>>>

March 11, 2020

Re: [Pharo-users] Generate class hierarchy from JSON Schema

by Esteban Maringolo

The profiling using the recordset was even worst. I changed the iteration [1] to add everything to a collection, but most of the time is spent in #calculateMethods and #calculateProperties. Which is performed everytime for each ADOField. I wouldn't consider this a stress test, but maybe the methods and properties should be cached, or a different class of dispatcher should be used where the methods and properties are defined ahead of time instead of being discovered when first invoked. Regards, [1] "Modified code" rst := ADORecordset createInstance . rst open: 'SELECT * FROM PLAYER' activeConnection: conn cursorType: 2 lockType: 3 options: -1. results := OrderedCollection new. [rst eof] whileFalse: [ | row | row := Array new: rst fields count. 1 to: row size do: [ :idx | row at: idx put: (rst fields item: idx) value ]. results add: row. rst moveNext ]. Esteban A. Maringolo On Wed, Mar 11, 2020 at 3:02 PM TomaÅ¾ Turk <tomaz.turk(a)ef.uni-lj.si> wrote: > Hi Esteban, > > Thanks for reporting this issue. I haven't made any "stress" tests yet for > ADOClient. Could you please try to use ADORecordset as described in the > readme? There you have a direct access to each record at a time, and then > you can create your own "loop" to process the query result. In this way you > can avoid the loop in ADOClient>>query: method. > > Best wishes, > Tomaz > > ------ Original Message ------ > From: "Esteban Maringolo" <emaringolo(a)gmail.com> > To: "TomaÅ¾ Turk" <tomaz.turk(a)ef.uni-lj.si>; "Any question about pharo is > welcome" <pharo-users(a)lists.pharo.org> > Sent: 11. 03. 2020 18:25:51 > Subject: Re: [Pharo-users] Generate class hierarchy from JSON Schema > > As an additional reference, I attach the profile tally for the query I'm > mentioning. > > The culprit seems to be the calculation of the ADOField properties that > might be calculated on every call. > > Regards, > > Esteban A. Maringolo > > > On Wed, Mar 11, 2020 at 2:13 PM Esteban Maringolo <emaringolo(a)gmail.com> > wrote: > >> Hi, >> >> To feed a Pharo app I need to read from an old MDB file, via ODBC. >> >> So I tested PharoADO and, after adding a missing Variant Type [1], I got >> my query working (at least read only). >> >> However the time of ADOClient to return a query with 10K rows of 5 >> columns each is extremely slow (+65000ms) compared, e.g., with Dolphin >> Smalltalk via ODBC (62ms). >> >> The time of the execute call to return is instantaneous, so I think the >> issue might be in the creation of the result set. >> >> Is this a known issue? >> >> Should I check something else? >> >> Thanks in advance, >> >> >> [1] https://github.com/tesonep/pharo-com/pull/10 >> Esteban A. Maringolo >> >> >> On Fri, Jan 24, 2020 at 5:59 AM TomaÅ¾ Turk <tomaz.turk(a)ef.uni-lj.si> >> wrote: >> >>> >>> That would be amazing! >>> >>> I'm a Mac/Unix guy so I don't have access to the other platforms (I >>> suppose I could fire up an AWS Oracle). I can do mysql/mariadb, posgresql, >>> and sqlite. >>> >>> I'm pretty close to pushing my ActiveRecord extensions. I just need to >>> get many to many with link tables done and it is good to go. I spent a few >>> days "porting" the ruby inflector and its tests. >>> >>> As for database introspection, I am relying on this new method and the >>> result set format on DatabasePlatform. >>> >>> printSqlStatementToListColumnsInTable: aDatabaseTable inSchema: >>> schemaString on: aStream >>> " Format: >>> name | type | length | nullable | >>> default_value | pk >>> >>> -------------------------+-------------------+--------+----------+-----------------------+---- >>> id | character varying | 255 | 0 | >>> ''::character varying | 1 >>> >>> >>> This is great news about ActiveRecord! >>> >>> ADO is, unfortunately, a Windows library, so PharoADO is limited to >>> Windows. Maybe as a next step we should focus into Garage and the addition >>> of SQL Server and Oracle support. If I only had time ... >>> >>> StÃ©phane, thanks for the support. >>> >>> Best wishes, >>> Tomaz >>> >>> >>> >>> >>> >>> >>>

March 11, 2020

Re: issue with PharoLauncher

by Renaud de Villemeur

Hi again Apparently, the issue is on the VM side. I unpack the 9.0 VM into the 8.0 folder, and everything went fine. Looks like there is an issue on windows when getting the latest 8.0 VM. Looking the the dev mailing list, I can see a similar issue has been raised, when you have unzip program on your computer, that can corrupt the VM extraction archive Renaud Mar. 11, 2020, 13:38 by renaud.devillemeur(a)tuta.io: > Hi. > > Are there any recent update with PharoLauncher ? It worked fine yesterday, but today I cannot launch default 8.0 image. It fail with a debug message: Instance of ZnBufferedWriteStream did not understand #name. I'm surprised to receive such message, and can't find out what has change to get suddenly such behaviour. > > Pharo Launcher is the latest version: Pharo 1.9.2-2019.08.01 - This distribution was built August 01, 2019. > > I'm using default Pharo 8.0 VM and Image, all refreshed to their latest version. > However, the launcher is working well with default Pharo 9.0 VM and Image. > > Here is an extract of the log (full log attached) > Instance of ZnBufferedWriteStream did not understand #name > 11 March 2020 10:51:09.200161 am > > VM: Win32 - IX86 - 10.0 - CoInterpreter VMMaker.oscog-eem.2504 uuid: a00b0fad-c04c-47a6-8a11-5dbff110ac11 JanÂ 5 2019 > StackToRegisterMappingCogit VMMaker.oscog-eem.2504 uuid: a00b0fad-c04c-47a6-8a11-5dbff110ac11 JanÂ 5 2019 > VM: 201901051900 > https://github.com/OpenSmalltalk/opensmalltalk-vm.git> Date: Sat Jan 5 20:00:11 2019 CommitHash: 7a3c6b6 Plugins: 201901051900 > https://github.com/OpenSmalltalk/opensmalltalk-vm.git > > Image: Pharo7.0.3 [Build information: Pharo-7.0.3+build.158.sha.0903ade8a6c96633f07e0a7f1baa9a5d48cfdf55 (32 Bit)] > > ZnBufferedWriteStream(Object)>>doesNotUnderstand: #name > Receiver: a ZnBufferedWriteStream > Arguments and temporary variables: > aMessage: name > exception: MessageNotUnderstood: ZnBufferedWriteStream>>name > resumeValue: nil > Receiver's instance variables: > stream: BinaryFileStream: 'C:\Users\villemre\devzone\Pharo\images\Pharo 8.0 - 6...etc... > buffer: nil > position: 0 > > Any advice ? > Thanks > Renaud > >

March 11, 2020

Re: [Pharo-users] Generate class hierarchy from JSON Schema

by TomaÅ¾ Turk

Hi Esteban, Thanks for reporting this issue. I haven't made any "stress" tests yet for ADOClient. Could you please try to use ADORecordset as described in the readme? There you have a direct access to each record at a time, and then you can create your own "loop" to process the query result. In this way you can avoid the loop in ADOClient>>query: method. Best wishes, Tomaz ------ Original Message ------ From: "Esteban Maringolo" <emaringolo(a)gmail.com> To: "TomaÅ¾ Turk" <tomaz.turk(a)ef.uni-lj.si>; "Any question about pharo is welcome" <pharo-users(a)lists.pharo.org> Sent: 11. 03. 2020 18:25:51 Subject: Re: [Pharo-users] Generate class hierarchy from JSON Schema >As an additional reference, I attach the profile tally for the query >I'm mentioning. > >The culprit seems to be the calculation of the ADOField properties that >might be calculated on every call. > >Regards, > >Esteban A. Maringolo > > >On Wed, Mar 11, 2020 at 2:13 PM Esteban Maringolo ><emaringolo(a)gmail.com> wrote: >>Hi, >> >>To feed a Pharo app I need to read from an old MDB file, via ODBC. >> >>So I tested PharoADO and, after adding a missing Variant Type [1], I >>got my query working (at least read only). >> >>However the time of ADOClient to return a query with 10K rows of 5 >>columns each is extremely slow (+65000ms) compared, e.g., with Dolphin >>Smalltalk via ODBC (62ms). >> >>The time of the execute call to return is instantaneous, so I think >>the issue might be in the creation of the result set. >> >>Is this a known issue? >> >>Should I check something else? >> >>Thanks in advance, >> >> >>[1] https://github.com/tesonep/pharo-com/pull/10 >>Esteban A. Maringolo >> >> >>On Fri, Jan 24, 2020 at 5:59 AM TomaÅ¾ Turk <tomaz.turk(a)ef.uni-lj.si> >>wrote: >>> >>>>That would be amazing! >>>> >>>>I'm a Mac/Unix guy so I don't have access to the other platforms (I >>>>suppose I could fire up an AWS Oracle). I can do mysql/mariadb, >>>>posgresql, and sqlite. >>>> >>>>I'm pretty close to pushing my ActiveRecord extensions. I just need >>>>to get many to many with link tables done and it is good to go. I >>>>spent a few days "porting" the ruby inflector and its tests. >>>> >>>>As for database introspection, I am relying on this new method and >>>>the result set format on DatabasePlatform. >>>> >>>>printSqlStatementToListColumnsInTable: aDatabaseTable inSchema: >>>>schemaString on: aStream >>>>" Format: >>>> name | type | length | nullable | >>>>default_value | pk >>>>-------------------------+-------------------+--------+----------+-----------------------+---- >>>> id | character varying | 255 | 0 | >>>>''::character varying | 1 >>>> >>>> >>>This is great news about ActiveRecord! >>> >>>ADO is, unfortunately, a Windows library, so PharoADO is limited to >>>Windows. Maybe as a next step we should focus into Garage and the >>>addition of SQL Server and Oracle support. If I only had time ... >>> >>>StÃ©phane, thanks for the support. >>> >>>Best wishes, >>>Tomaz >>> >>> >>> >>> >>> >>>

March 11, 2020

issue with PharoLauncher

by Renaud de Villemeur

Hi. Are there any recent update with PharoLauncher ? It worked fine yesterday, but today I cannot launch default 8.0 image. It fail with a debug message: Instance of ZnBufferedWriteStream did not understand #name. I'm surprised to receive such message, and can't find out what has change to get suddenly such behaviour. Pharo Launcher is the latest version: Pharo 1.9.2-2019.08.01 - This distribution was built August 01, 2019. I'm using default Pharo 8.0 VM and Image, all refreshed to their latest version. However, the launcher is working well with default Pharo 9.0 VM and Image. Here is an extract of the log (full log attached) Instance of ZnBufferedWriteStream did not understand #name 11 March 2020 10:51:09.200161 am VM: Win32 - IX86 - 10.0 - CoInterpreter VMMaker.oscog-eem.2504 uuid: a00b0fad-c04c-47a6-8a11-5dbff110ac11 JanÂ 5 2019 StackToRegisterMappingCogit VMMaker.oscog-eem.2504 uuid: a00b0fad-c04c-47a6-8a11-5dbff110ac11 JanÂ 5 2019 VM: 201901051900 https://github.com/OpenSmalltalk/opensmalltalk-vm.git Date: Sat Jan 5 20:00:11 2019 CommitHash: 7a3c6b6 Plugins: 201901051900 https://github.com/OpenSmalltalk/opensmalltalk-vm.git Image: Pharo7.0.3 [Build information: Pharo-7.0.3+build.158.sha.0903ade8a6c96633f07e0a7f1baa9a5d48cfdf55 (32 Bit)] ZnBufferedWriteStream(Object)>>doesNotUnderstand: #name Receiver: a ZnBufferedWriteStream Arguments and temporary variables: aMessage: name exception: MessageNotUnderstood: ZnBufferedWriteStream>>name resumeValue: nil Receiver's instance variables: stream: BinaryFileStream: 'C:\Users\villemre\devzone\Pharo\images\Pharo 8.0 - 6...etc... buffer: nil position: 0 Any advice ? Thanks Renaud

March 11, 2020