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 discover
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 man
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
wrote:
> I did a s
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.
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 method
--- Begin Message ---
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 yo
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. I
--- Begin Message ---
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 w
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
wrote:
> Hi,
>
> To
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) comp
Dear friends,
I would like to comment that Sebastian, an intern of my company, just
ported the MatchTool to Pharo 9. You may find the install instructions in
the following link :)
https://github.com/jordanmontt/MatchTool-Spec2
Please, help us to test it, any feedback is welcome.
Regards,
Juan
11 matches
Mail list logo