[Pharo-users] StCAD is open source

[askoh]

Hi:

I have just open source StCAD (MIT license) which has the code for freeCAD.
http://askoh.com/stcad
Although written in VisualWorks Smalltalk, I hope Pharo users will port it
in part or whole.

All the best,
Aik-Siong Koh

What is 'StCAD'?

'StCAD' is a basic 3D CAD framework in Smalltalk (VisualWorks 8.x). It
extends
the GF/ST 2D drawing framework into 3D. It also include 'StCAD-Geo' which is
the 3D geometric domain, 'StCAD-Math' which provides the mathematical
support
for 3D CAD and motion simulation computations, and 'StCAD-Doc' which is a
simple word processor. 'StCAD-Math' is also suitable for engineering,
scientific and business computing. The parcels are open source using MIT
License. Users can use these parcels with other private software to create
3D
applications like motion simulation, finite element analysis, CAD,
scientific
visualization, etc.

'StCAD' allows users to create and manipulate assemblies, which are
collections of 3D parts. The parts are 3D solids, which can be connected by
joints, constraints, contacts, actuators, springs, dampers or forces. The
parts and connections define the structure or mechanism that the assembly is
meant to represent. Animation is possible, if the user can provide time
series
of position and orientation data for the parts.

Users can also obtain output data in the form of plots and tables. XY plots
can be zoomed and set to equal scales. Data series available include linear
and angular displacements, velocities, accelerations and other user
generated
data.

'StCAD' has been used to create a freeware called 'freeCAD' which is a 3D
CAD
with Motion Simulation. For more information visit:
http://www.askoh.com





--
Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html

[Pharo-users] StCAD is open source

[askoh]

Hi:

I have just open source StCAD (MIT license) which has the code for freeCAD.
http://askoh.com/stcad
Although written in VisualWorks, I hope Pharo developers can port it in part
or whole.

All the best,
Aik-Siong Koh

What is 'StCAD'?

'StCAD' is a basic 3D CAD framework in Smalltalk (VisualWorks 8.x). It
extends
the GF/ST 2D drawing framework into 3D. It also include 'StCAD-Geo' which is
the 3D geometric domain, 'StCAD-Math' which provides the mathematical
support
for 3D CAD and motion simulation computations, and 'StCAD-Doc' which is a
simple word processor. 'StCAD-Math' is also suitable for engineering,
scientific and business computing. The parcels are open source using MIT
License. Users can use these parcels with other private software to create
3D
applications like motion simulation, finite element analysis, CAD,
scientific
visualization, etc.

'StCAD' allows users to create and manipulate assemblies, which are
collections of 3D parts. The parts are 3D solids, which can be connected by
joints, constraints, contacts, actuators, springs, dampers or forces. The
parts and connections define the structure or mechanism that the assembly is
meant to represent. Animation is possible, if the user can provide time
series
of position and orientation data for the parts.

Users can also obtain output data in the form of plots and tables. XY plots
can be zoomed and set to equal scales. Data series available include linear
and angular displacements, velocities, accelerations and other user
generated
data.

'StCAD' has been used to create a freeware called 'freeCAD' which is a 3D
CAD
with Motion Simulation. For more information visit:
http://www.askoh.com





--
Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html

Re: [Pharo-users] OmniBase for Pharo 6

[PBKResearch]

Matias

 

Thanks for your report. Since it is working so well for you, I think it is time 
for me to give up working on the test suite and start using it for real. That 
will be for tomorrow (it’s almost midnight here now!).

 

I have realised, by the way, that there is an easy work round for the Date 
problem. If you need to persist a Date with full time-zone consistency, just 
apply ‘start’ to it, which gives a DateAndTime. This will be stored and 
retrieved correctly. When it has been retrieved, just send asDate  to recover 
the correct date.

 

Best wishes

 

Peter Kenny

 

From: Pharo-users  On Behalf Of Matias 
Maretto
Sent: 24 June 2018 23:33
To: Any question about pharo is welcome 
Subject: Re: [Pharo-users] OmniBase for Pharo 6

 

Thank you for the info Peter ; I have been working storing and retrieving data 
, everything works fine. I have an ODBPErsistDictionary with almost 20.000 
objects on it, I really get sorprised of how fast can resolve "select:[] 
commands"; I know it is not related with the subjet we are working, but well  

 

 

 

  _  

De: Pharo-users mailto:pharo-users-boun...@lists.pharo.org> > en nombre de PBKResearch 
mailto:pe...@pbkresearch.co.uk> >
Enviado: domingo, 24 de junio de 2018 05:54 p. m.
Para: 'Any question about pharo is welcome'
Asunto: Re: [Pharo-users] OmniBase for Pharo 6 

 

Hi Matias (and EstebanLM)

 

I have explained the problem with storing and retrieving Date. Looking through 
the OmniBase code in the repository, I see that there is a whole series of 
extensions for many of the standard classes, which provide methods for 
serializing and deserializing instances of those classes. The extension for 
Date class ignores the start time, and simply saves the day number; the 
retrieval method can only use the days, and so cannot take account of the 
offset for the time zone. If it is necessary to save and restore dates in a way 
which is time-zone sensitive, it will be necessary to modify the code for 
serializing dates to store day and offset. I have not yet worked out how the 
methods are structured, so I have not tried to recode, but all the methods I 
have looked at are only one or two lines, so it should not be difficult.

 

Looking through the classes with extensions, I realise that we may need to 
check rather more examples to be sure that everything is handled correctly. I 
did one little test with String. The standard test in TestEquality just stores 
and retrieves ‘Hello World’. To check that it could handle other encodings, I 
tried the test with a German string encoded in utf8. This worked OK. So thus 
far everything is fine, but it would be a good idea to check correct retrieval 
each time we persist a new class of object.

 

Best wishes

 

Peter Kenny

 

From: Pharo-users mailto:pharo-users-boun...@lists.pharo.org> > On Behalf Of Matias Maretto
Sent: 23 June 2018 19:40
To: Any question about pharo is welcome mailto:pharo-users@lists.pharo.org> >
Subject: Re: [Pharo-users] OmniBase for Pharo 6

 

Hi Peter, thanks for the news. I have been doing some tests, persisting 
diferent kind of objects and until now everythings works fine.

If you find anything else, please let me now.

 

Thanks.

Matias.

 

 

  _  

De: Pharo-users mailto:pharo-users-boun...@lists.pharo.org> > en nombre de PBKResearch 
mailto:pe...@pbkresearch.co.uk> >
Enviado: sábado, 23 de junio de 2018 05:18 p. m.
Para: 'Any question about pharo is welcome'
Asunto: Re: [Pharo-users] OmniBase for Pharo 6 

 

Hi Matias

 

A further report. I have worked through the test suite in OmniBaseTests, 
running each test individually. I now have all green except two – testEquality, 
which fails on the storage and retrieval of ‘Date today’, and testGC, which 
fails for reasons I have not yet found.

 

The worrying thing is the apparent change in the instance variables of Date – 
see my exchange with Alistair Grant in another thread. I shall try to work 
through the way OmniBase saves and resets the instvars, just in case it might 
be a general problem.

 

I shall let you know of anything else I find.

 

Peter Kenny

 

From: Pharo-users mailto:pharo-users-boun...@lists.pharo.org> > On Behalf Of PBKResearch
Sent: 23 June 2018 09:18
To: 'Any question about pharo is welcome' mailto:pharo-users@lists.pharo.org> >
Subject: Re: [Pharo-users] OmniBase for Pharo 6

 

Matias

 

Thanks. I have made this change, but it does not affect the tests I have run.

 

I have focused on getting the test suite in OmniBaseTests to run. So far I 
still have 5 greens, 7 reds and one orange. The greens are all the first five 
test methods in the browser list; it seems it half fails on the sixth one 
(TestEquality), hence the orange, and then red for all the rest.

 

One problem is that the test database is created at the start of the test 
suite, and then not removed at the end. This seems to mess up the next attempt 
to run the tests. I tried to run the OmniBaseTests>>#tearDown manually, 

Re: [Pharo-users] OmniBase for Pharo 6

[Matias Maretto]

Thank you for the info Peter ; I have been working storing and retrieving data 
, everything works fine. I have an ODBPErsistDictionary with almost 20.000 
objects on it, I really get sorprised of how fast can resolve "select:[] 
commands"; I know it is not related with the subjet we are working, but well 





De: Pharo-users  en nombre de PBKResearch 

Enviado: domingo, 24 de junio de 2018 05:54 p. m.
Para: 'Any question about pharo is welcome'
Asunto: Re: [Pharo-users] OmniBase for Pharo 6


Hi Matias (and EstebanLM)



I have explained the problem with storing and retrieving Date. Looking through 
the OmniBase code in the repository, I see that there is a whole series of 
extensions for many of the standard classes, which provide methods for 
serializing and deserializing instances of those classes. The extension for 
Date class ignores the start time, and simply saves the day number; the 
retrieval method can only use the days, and so cannot take account of the 
offset for the time zone. If it is necessary to save and restore dates in a way 
which is time-zone sensitive, it will be necessary to modify the code for 
serializing dates to store day and offset. I have not yet worked out how the 
methods are structured, so I have not tried to recode, but all the methods I 
have looked at are only one or two lines, so it should not be difficult.



Looking through the classes with extensions, I realise that we may need to 
check rather more examples to be sure that everything is handled correctly. I 
did one little test with String. The standard test in TestEquality just stores 
and retrieves ‘Hello World’. To check that it could handle other encodings, I 
tried the test with a German string encoded in utf8. This worked OK. So thus 
far everything is fine, but it would be a good idea to check correct retrieval 
each time we persist a new class of object.



Best wishes



Peter Kenny



From: Pharo-users  On Behalf Of Matias 
Maretto
Sent: 23 June 2018 19:40
To: Any question about pharo is welcome 
Subject: Re: [Pharo-users] OmniBase for Pharo 6



Hi Peter, thanks for the news. I have been doing some tests, persisting 
diferent kind of objects and until now everythings works fine.

If you find anything else, please let me now.



Thanks.

Matias.







De: Pharo-users 
mailto:pharo-users-boun...@lists.pharo.org>>
 en nombre de PBKResearch 
mailto:pe...@pbkresearch.co.uk>>
Enviado: sábado, 23 de junio de 2018 05:18 p. m.
Para: 'Any question about pharo is welcome'
Asunto: Re: [Pharo-users] OmniBase for Pharo 6



Hi Matias



A further report. I have worked through the test suite in OmniBaseTests, 
running each test individually. I now have all green except two – testEquality, 
which fails on the storage and retrieval of ‘Date today’, and testGC, which 
fails for reasons I have not yet found.



The worrying thing is the apparent change in the instance variables of Date – 
see my exchange with Alistair Grant in another thread. I shall try to work 
through the way OmniBase saves and resets the instvars, just in case it might 
be a general problem.



I shall let you know of anything else I find.



Peter Kenny



From: Pharo-users 
mailto:pharo-users-boun...@lists.pharo.org>>
 On Behalf Of PBKResearch
Sent: 23 June 2018 09:18
To: 'Any question about pharo is welcome' 
mailto:pharo-users@lists.pharo.org>>
Subject: Re: [Pharo-users] OmniBase for Pharo 6



Matias



Thanks. I have made this change, but it does not affect the tests I have run.



I have focused on getting the test suite in OmniBaseTests to run. So far I 
still have 5 greens, 7 reds and one orange. The greens are all the first five 
test methods in the browser list; it seems it half fails on the sixth one 
(TestEquality), hence the orange, and then red for all the rest.



One problem is that the test database is created at the start of the test 
suite, and then not removed at the end. This seems to mess up the next attempt 
to run the tests. I tried to run the OmniBaseTests>>#tearDown manually, but it 
fails, so I have to exit Pharo and delete the test database in Windows.



I intend to continue running the test suite, but I shall run the tests 
individually, and put breakpoints in those that fail. I shall report here if I 
make any progress.



Best wishes



Peter Kenny



From: Pharo-users 
mailto:pharo-users-boun...@lists.pharo.org>>
 On Behalf Of Matias Maretto
Sent: 23 June 2018 01:37
To: Any question about pharo is welcome 
mailto:pharo-users@lists.pharo.org>>
Subject: Re: [Pharo-users] OmniBase for Pharo 6



Peter: I think I found the problem. On ODBFileStream class >> 
accessModeReadOnly the "o" on "only" is not capital. It is  
^#accessModeReadonly  when should be ^#accessModeReadOnly ; so on the 
ODBWin32FileStream >> createOn:  createMode:  accessMode:  shareMode:  
cacheMode:  this part fails:

accessMode = #accessModeReadOnly ifTrue: [acMode := 2147483648 

Re: [Pharo-users] OmniBase for Pharo 6

[PBKResearch]

Hi Matias (and EstebanLM)

 

I have explained the problem with storing and retrieving Date. Looking
through the OmniBase code in the repository, I see that there is a whole
series of extensions for many of the standard classes, which provide methods
for serializing and deserializing instances of those classes. The extension
for Date class ignores the start time, and simply saves the day number; the
retrieval method can only use the days, and so cannot take account of the
offset for the time zone. If it is necessary to save and restore dates in a
way which is time-zone sensitive, it will be necessary to modify the code
for serializing dates to store day and offset. I have not yet worked out how
the methods are structured, so I have not tried to recode, but all the
methods I have looked at are only one or two lines, so it should not be
difficult.

 

Looking through the classes with extensions, I realise that we may need to
check rather more examples to be sure that everything is handled correctly.
I did one little test with String. The standard test in TestEquality just
stores and retrieves ‘Hello World’. To check that it could handle other
encodings, I tried the test with a German string encoded in utf8. This
worked OK. So thus far everything is fine, but it would be a good idea to
check correct retrieval each time we persist a new class of object.

 

Best wishes

 

Peter Kenny

 

From: Pharo-users  On Behalf Of Matias
Maretto
Sent: 23 June 2018 19:40
To: Any question about pharo is welcome 
Subject: Re: [Pharo-users] OmniBase for Pharo 6

 

Hi Peter, thanks for the news. I have been doing some tests, persisting
diferent kind of objects and until now everythings works fine.

If you find anything else, please let me now.

 

Thanks.

Matias.

 

 

  _  

De: Pharo-users mailto:pharo-users-boun...@lists.pharo.org> > en nombre de PBKResearch
mailto:pe...@pbkresearch.co.uk> >
Enviado: sábado, 23 de junio de 2018 05:18 p. m.
Para: 'Any question about pharo is welcome'
Asunto: Re: [Pharo-users] OmniBase for Pharo 6 

 

Hi Matias

 

A further report. I have worked through the test suite in OmniBaseTests,
running each test individually. I now have all green except two –
testEquality, which fails on the storage and retrieval of ‘Date today’, and
testGC, which fails for reasons I have not yet found.

 

The worrying thing is the apparent change in the instance variables of Date
– see my exchange with Alistair Grant in another thread. I shall try to work
through the way OmniBase saves and resets the instvars, just in case it
might be a general problem.

 

I shall let you know of anything else I find.

 

Peter Kenny

 

From: Pharo-users mailto:pharo-users-boun...@lists.pharo.org> > On Behalf Of PBKResearch
Sent: 23 June 2018 09:18
To: 'Any question about pharo is welcome' mailto:pharo-users@lists.pharo.org> >
Subject: Re: [Pharo-users] OmniBase for Pharo 6

 

Matias

 

Thanks. I have made this change, but it does not affect the tests I have
run.

 

I have focused on getting the test suite in OmniBaseTests to run. So far I
still have 5 greens, 7 reds and one orange. The greens are all the first
five test methods in the browser list; it seems it half fails on the sixth
one (TestEquality), hence the orange, and then red for all the rest.

 

One problem is that the test database is created at the start of the test
suite, and then not removed at the end. This seems to mess up the next
attempt to run the tests. I tried to run the OmniBaseTests>>#tearDown
manually, but it fails, so I have to exit Pharo and delete the test database
in Windows.

 

I intend to continue running the test suite, but I shall run the tests
individually, and put breakpoints in those that fail. I shall report here if
I make any progress.

 

Best wishes

 

Peter Kenny

 

From: Pharo-users mailto:pharo-users-boun...@lists.pharo.org> > On Behalf Of Matias Maretto
Sent: 23 June 2018 01:37
To: Any question about pharo is welcome mailto:pharo-users@lists.pharo.org> >
Subject: Re: [Pharo-users] OmniBase for Pharo 6

 

Peter: I think I found the problem. On ODBFileStream class >>
accessModeReadOnly the "o" on "only" is not capital. It is
^#accessModeReadonly  when should be ^#accessModeReadOnly ; so on the
ODBWin32FileStream >> createOn:  createMode:  accessMode:  shareMode:
cacheMode:  this part fails:

accessMode = #accessModeReadOnly ifTrue: [acMode := 2147483648
"GENERIC_READ"].

So it cant open the users file for read.  I have fix it and at least for now
I didn't get any "block" error. 

 

 

 

  _  

De: Pharo-users mailto:pharo-users-boun...@lists.pharo.org> > en nombre de PBKResearch
mailto:pe...@pbkresearch.co.uk> >
Enviado: viernes, 22 de junio de 2018 10:39 p. m.
Para: 'Any question about pharo is welcome'
Asunto: Re: [Pharo-users] OmniBase for Pharo 6 

 

Matias

 

Thanks for the hints. I now have 5 greens, but all the rest are red. I am
still getting the ‘File cannot be locked’ message. Are you doing better than

[Pharo-users] EXIF / JPEG metadata

[Alistair Grant]

Hi Everyone,

As far as I can tell, JPEGReadWriter in Pharo 7 doesn't read (or
write) the image metadata, e.g. title, keywords, exposure time, etc.

Is anyone aware of a package that does?

Thanks!
Alistair

Re: [Pharo-users] [ANN] Pharo Launcher v1.2 release

[Sean P. DeNigris]

SergeStinckwich wrote
> ​Yes maybe only have the warnings on Linux made more sense. ​

That seems like a much less intrusive path…

PharoLauncher-Core-SeanDeNigris.200 - Only Warn RE 32-bit on Linux 64
Re-opened and updated issue



-
Cheers,
Sean
--
Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html

Re: [Pharo-users] copy & paste

[Hilaire]

Hi Otto,

I had this issue, but it seems to be gone with P7, at least on the DrGeo
build based on it I can copy and paste from Chromium.

Hilaire


Le 24/06/2018 à 11:11, Otto Behrens a écrit :
>
> A very annoying issue I'm having with Pharo 6.0 (running on Ubuntu
> 16.04) is that if I copy text from other applications (eg. chromium
> browser), I cannot paste it into Pharo. I get text copied in Pharo
> from a previous copy.
>
-- 
Dr. Geo
http://drgeo.eu

Re: [Pharo-users] copy & paste

[Peter Uhnák]

Also this, but I think that it was changed in the VM later

http://forum.world.st/Re-Copy-past-doesn-t-work-sometimes-in-Chrome-semifixed-td4784604.html

On Sun, Jun 24, 2018 at 11:31 AM, Peter Uhnák  wrote:

> I thought that this was fixed a long time ago?
>
> Try running it with  --textenc utf8  and see if it fixes it.
>
> Peter
>
> On Sun, Jun 24, 2018 at 11:11 AM, Otto Behrens  wrote:
>
>> Hi,
>>
>> A very annoying issue I'm having with Pharo 6.0 (running on Ubuntu 16.04)
>> is that if I copy text from other applications (eg. chromium browser), I
>> cannot paste it into Pharo. I get text copied in Pharo from a previous copy.
>>
>> To work around this, I have a "gedit" text editor open and I paste the
>> text in there. After that, I cut it from the text editor and paste it into
>> pharo.
>>
>> So, it appears as if this may be an issue with text (/encoding?). Any
>> ideas?
>>
>> Thanks
>> Otto
>>
>
>

Re: [Pharo-users] copy & paste

[Peter Uhnák]

I thought that this was fixed a long time ago?

Try running it with  --textenc utf8  and see if it fixes it.

Peter

On Sun, Jun 24, 2018 at 11:11 AM, Otto Behrens  wrote:

> Hi,
>
> A very annoying issue I'm having with Pharo 6.0 (running on Ubuntu 16.04)
> is that if I copy text from other applications (eg. chromium browser), I
> cannot paste it into Pharo. I get text copied in Pharo from a previous copy.
>
> To work around this, I have a "gedit" text editor open and I paste the
> text in there. After that, I cut it from the text editor and paste it into
> pharo.
>
> So, it appears as if this may be an issue with text (/encoding?). Any
> ideas?
>
> Thanks
> Otto
>

[Pharo-users] copy & paste

[Otto Behrens]

Hi,

A very annoying issue I'm having with Pharo 6.0 (running on Ubuntu 16.04)
is that if I copy text from other applications (eg. chromium browser), I
cannot paste it into Pharo. I get text copied in Pharo from a previous copy.

To work around this, I have a "gedit" text editor open and I paste the text
in there. After that, I cut it from the text editor and paste it into pharo.

So, it appears as if this may be an issue with text (/encoding?). Any ideas?

Thanks
Otto

Re: [Pharo-users] Strange Result - OmniBase bug or Date feature?

[Esteban Lorenzano]

> On 24 Jun 2018, at 10:02, Esteban Lorenzano  wrote:
> 
> 
> 
>> On 23 Jun 2018, at 18:09, PBKResearch > > wrote:
>> 
>> Retransmit with additional information: All tests with Windows 10 with all 
>> recent updates
>>  
>> Hello All
>>  
>> I am experimenting with the version of OmniBase which Esteban Lorenzano 
>> posted a few days ago. With corrections posted by Matias Moretto, who is 
>> working on the same track, I have got the first five tests all green. On the 
>> sixth test, OmniBaseTest>>#testEquality, I have run into a strange failure. 
>> I don’t know whether it shows that OmniBase is not recovering data 
>> correctly, or whether it is a feature of the way Date is implemented in 
>> Pharo. (I still have Dolphin 6 on my machine, including OmniBase, and there 
>> the same test passes.)
>>  
>> The test simply constructs a collection of various types of object, stores 
>> the whole collection on the database, retrieves it and compares each 
>> retrieved element with the corresponding element of the original collection. 
>> One element is obtained by evaluating ‘Date today’, and that is the one that 
>> fails. The test failure description is: ‘Got 23 June 2018 instead of 23 June 
>> 2018.’ Using the inspector, I can see that the retrieved date differs from 
>> the original in that the instvar ‘start’ has a Julian Day Number which is 
>> one greater, but seconds as zero instead of 82800 and an offset of zero 
>> instead of 1:00:00. In fact 82800 seconds is 23 hours, so all these add up 
>> to the same start time, just differently represented.
>>  
>> To get round the failure, I changed the constructor of the test collection 
>> to use ‘Date today printString’, which of course meant it worked perfectly. 
>> My worry is whether in some other context the change of the innards of the 
>> object might have an adverse effect. I don’t understand why the Date 
>> constructor represents the start of today as 23 hours after 1 a.m. 
>> yesterday. Is the change something OmniBase has done in storing and 
>> retrieving, or is it due to the way the Date is reconstructed?
>>  
>> Just for fun, I used Fuel to serialize and re-materialize Date today; it did 
>> not make any changes.
>>  
>> Does this reinforce Todd’s suggestion that OmniBase is not reliable, or is 
>> it just a quirk?
>>  
>> Any ideas gratefully received
> 
> 
> no idea about it but… feel free to send me a PR (and I will move the port to 
> pharo-nosql group as is not “my” project) :)

and btw if you or anyone else wants to take the responsibility of keeping that 
project, I will gladly add you as maintainers of it. As I said, I’m not the 
right one to do it since I do not work with OmniBase in general… even if I 
wanted to create a layer on voyage for it (also a possible sub-project I 
recommend to look at it) 

cheers, 
Esteban

> 
> cheers!
> Esteban
> 
> 
> 
>>  
>> Peter Kenny

Re: [Pharo-users] Strange Result - OmniBase bug or Date feature?

[Esteban Lorenzano]

> On 23 Jun 2018, at 18:09, PBKResearch  wrote:
> 
> Retransmit with additional information: All tests with Windows 10 with all 
> recent updates
>  
> Hello All
>  
> I am experimenting with the version of OmniBase which Esteban Lorenzano 
> posted a few days ago. With corrections posted by Matias Moretto, who is 
> working on the same track, I have got the first five tests all green. On the 
> sixth test, OmniBaseTest>>#testEquality, I have run into a strange failure. I 
> don’t know whether it shows that OmniBase is not recovering data correctly, 
> or whether it is a feature of the way Date is implemented in Pharo. (I still 
> have Dolphin 6 on my machine, including OmniBase, and there the same test 
> passes.)
>  
> The test simply constructs a collection of various types of object, stores 
> the whole collection on the database, retrieves it and compares each 
> retrieved element with the corresponding element of the original collection. 
> One element is obtained by evaluating ‘Date today’, and that is the one that 
> fails. The test failure description is: ‘Got 23 June 2018 instead of 23 June 
> 2018.’ Using the inspector, I can see that the retrieved date differs from 
> the original in that the instvar ‘start’ has a Julian Day Number which is one 
> greater, but seconds as zero instead of 82800 and an offset of zero instead 
> of 1:00:00. In fact 82800 seconds is 23 hours, so all these add up to the 
> same start time, just differently represented.
>  
> To get round the failure, I changed the constructor of the test collection to 
> use ‘Date today printString’, which of course meant it worked perfectly. My 
> worry is whether in some other context the change of the innards of the 
> object might have an adverse effect. I don’t understand why the Date 
> constructor represents the start of today as 23 hours after 1 a.m. yesterday. 
> Is the change something OmniBase has done in storing and retrieving, or is it 
> due to the way the Date is reconstructed?
>  
> Just for fun, I used Fuel to serialize and re-materialize Date today; it did 
> not make any changes.
>  
> Does this reinforce Todd’s suggestion that OmniBase is not reliable, or is it 
> just a quirk?
>  
> Any ideas gratefully received


no idea about it but… feel free to send me a PR (and I will move the port to 
pharo-nosql group as is not “my” project) :)

cheers!
Esteban



>  
> Peter Kenny