June 2018 - Pharo-users - lists.pharo.org

Re: [Pharo-users] copy & paste

by 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-semifix… On Sun, Jun 24, 2018 at 11:31 AM, Peter UhnÃ¡k <i.uhnak(a)gmail.com> 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 <otto(a)finworks.biz> 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 >> > >

June 24, 2018

Re: [Pharo-users] copy & paste

by 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 <otto(a)finworks.biz> 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 >

June 24, 2018

copy & paste

by 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

June 24, 2018

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

by Esteban Lorenzano

> On 24 Jun 2018, at 10:02, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > > > >> On 23 Jun 2018, at 18:09, PBKResearch <peter(a)pbkresearch.co.uk <mailto:peter@pbkresearch.co.uk>> 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

June 24, 2018

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

by Esteban Lorenzano

> On 23 Jun 2018, at 18:09, PBKResearch <peter(a)pbkresearch.co.uk> 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

June 24, 2018

Re: [Pharo-users] Pharo 7 streams API

by Ben Coman

On 24 June 2018 at 00:53, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > Peter, > > > On 23 Jun 2018, at 15:39, Peter UhnÃ¡k <i.uhnak(a)gmail.com> wrote: > > > > Hi, > > > > I'm starting to familiarize myself with new streams, and one thing I've > noticed is the removal of #lineEndConvention (which I use all the time). > > > > So a statement like this > > > > aFile writeStreamDo: [ :stream | > > stream lineEndConvention: #lf. > > stream << '...' > > ]. > > > > has to be written like so > > > > aFile writeStreamDo: [ :rawStream | |stream| > > stream := (ZnNewLineWriterStream on: rawStream) forLf. > > stream << '...' > > ]. > > > > which feels very messy because I am mixing writing with the > configuration. And I don't even take account for buffered/encoded > decorators. Plus it increases the incidental complexity -- I need another > variable, and I can accidentally write to the wrong stream, etc. > > > > Would a method like #writeStream:do: (or #writeStreamTransform:do:) make > sense? E.g. > > > > aFile writeStreamTransform: [ :stream | (ZnNewLineWriterStream on: > stream) ] do: [ :stream | > > stream << '...' > > ] > > > > To separate the composition from the usage? > > > > Thanks, > > Peter > > The goals of the 'new' (they have existed for quite a while) streams is to > go from single big complex do all classes and replace that with a > composition of much simpler single purpose classes. Another goal is to > reduce the API so that it becomes easier to create new stream classes. Of > course, a consequence is that you need composition to get the functionality > you want. But I think you understand the tradeoff. > > If the mixing of configuration/setup with writing/reading bothers you, > then I would suggest using two methods. One that does only the > writing/reading assuming a limited API, and another that does the > configuration/setup, using composition. > > Note that the streams that you get already are a composition (most often a > BinaryFileStream wrapped in a Buffered stream wrapped in a > Encoding/Decoding stream). EOL translation is not a standard part of that. > But there is quite some system code that does uses EOL translation. There may be performance implications for streams opened frequently, but perhaps something like this would be useful...?? aFile writeStreamDo: [ :stream | stream becomeWrappedBy: ( ZnNewLineWriterStream new forLf). stream << '...' cheers -ben

June 24, 2018

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

by Sean P. DeNigris

Peter Kenny wrote > luckily I did not have anything major planned for the weekend! Or else I > should just follow Todd's advice. Glad you had a boring weekend planned - it seems we all will benefit ;-) Keep going and asking questions! ----- Cheers, Sean -- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html

June 23, 2018

Re: [Pharo-users] OmniBase for Pharo 6

by Matias Maretto

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 <pharo-users-bounces(a)lists.pharo.org> en nombre de PBKResearch <peter(a)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 <pharo-users-bounces(a)lists.pharo.org> On Behalf Of PBKResearch Sent: 23 June 2018 09:18 To: 'Any question about pharo is welcome' <pharo-users(a)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 <pharo-users-bounces(a)lists.pharo.org<mailto:pharo-users-bounces@lists.pharo.org>> On Behalf Of Matias Maretto Sent: 23 June 2018 01:37 To: Any question about pharo is welcome <pharo-users(a)lists.pharo.org<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 <pharo-users-bounces(a)lists.pharo.org<mailto:pharo-users-bounces@lists.pharo.org>> en nombre de PBKResearch <peter(a)pbkresearch.co.uk<mailto:peter@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 that? I may try a few trials using it for real, rather than the test suite. Thanks again Peter Kenny From: Pharo-users <pharo-users-bounces(a)lists.pharo.org<mailto:pharo-users-bounces@lists.pharo.org>> On Behalf Of Matias Maretto Sent: 22 June 2018 22:54 To: Any question about pharo is welcome <pharo-users(a)lists.pharo.org<mailto:pharo-users@lists.pharo.org>> Subject: Re: [Pharo-users] OmniBase for Pharo 6 Hi Peter, yes I had the same error at the beginning. I have done 2 minor changes. Now it seems to be working fine (Although I am still running more tests). Here: ODBWin32FileStream >> closeHandle: aHandle "Close an open Win32 object handle, freeing any resources held by it. Once closed a handle is no longer valid. Answer whether the function succeeds. See Win32 SDK help for more information. BOOL CloseHandle( HANDLE hObject // handle of object to close );" "<apicall: ulong 'CloseHandle' (long) module:'kernel32.dll'>" ^ self ffiCall: #(ulong CloseHandle(long aHandle)) ODBWin32FileStream >> lockFile: aHandle offsetLow: loPos offsetHigh: hiPos lengthLow: loLength lengthHigh: hiLength "<apicall: long 'LockFile' (long ulong ulong ulong ulong) module: 'kernel32.dll'>" ^ self ffiCall: #(long LockFile #(long aHandle , ulong loPos , ulong hiPos , ulong loLength , ulong hiLength)) ________________________________ De: Pharo-users <pharo-users-bounces(a)lists.pharo.org<mailto:pharo-users-bounces@lists.pharo.org>> en nombre de PBKResearch <peter(a)pbkresearch.co.uk<mailto:peter@pbkresearch.co.uk>> Enviado: viernes, 22 de junio de 2018 09:45 p. m. Para: 'Any question about pharo is welcome' Asunto: Re: [Pharo-users] OmniBase for Pharo 6 Matias I have just loaded Estebanâs package in a new Pharo 6.1 under Windows 10. I get an error message saying âFile cannot be locked. Try again?â. When I select ânoâ, all tests are run and give red. Are you still running on win 7? If so, I must be doing something wrong. Can you give more details of the FFI corrections you made, please? Many thanks Peter Kenny From: Pharo-users <pharo-users-bounces(a)lists.pharo.org<mailto:pharo-users-bounces@lists.pharo.org>> On Behalf Of Matias Maretto Sent: 22 June 2018 21:07 To: Any question about pharo is welcome <pharo-users(a)lists.pharo.org<mailto:pharo-users@lists.pharo.org>> Subject: Re: [Pharo-users] OmniBase for Pharo 6 Esteban: it's working fine, I had to made a minor corrections on 2 FFI calls and now everithing seems to be working fine. For What I saw with Voyage-UnqLite only String Objects can be used to searilize; Omnibase allow to persist almost any kind of objects, thats the part I like about it. ________________________________ De: Pharo-users <pharo-users-bounces(a)lists.pharo.org<mailto:pharo-users-bounces@lists.pharo.org>> en nombre de Esteban Lorenzano <estebanlm(a)gmail.com<mailto:estebanlm@gmail.com>> Enviado: jueves, 21 de junio de 2018 08:19 p. m. Para: Any question about pharo is welcome Asunto: Re: [Pharo-users] OmniBase for Pharo 6 I did it manually and I took like 5 min :P but this was really easy, just a bunch of FFI calls. Esteban > On 21 Jun 2018, at 15:31, Sean P. DeNigris <sean(a)clipperadams.com<mailto:sean@clipperadams.com>> wrote: > > EstebanLM wrote >> I just made a âblind portââ¦ migrated the old FFI to new UFFI > > Did you do this manually or use some migration tool? How long did it take? > > > > ----- > Cheers, > Sean > -- > Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html Smalltalk - Pharo Smalltalk Users | Mailing List Archive<http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html> forum.world.st Pharo Smalltalk Users forum and mailing list archive. Pharo User Forum >

June 23, 2018

Re: [Pharo-users] OmniBase for Pharo 6

by PBKResearch

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 <pharo-users-bounces(a)lists.pharo.org> On Behalf Of PBKResearch Sent: 23 June 2018 09:18 To: 'Any question about pharo is welcome' <pharo-users(a)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 <pharo-users-bounces(a)lists.pharo.org <mailto:pharo-users-bounces@lists.pharo.org> > On Behalf Of Matias Maretto Sent: 23 June 2018 01:37 To: Any question about pharo is welcome <pharo-users(a)lists.pharo.org <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 <pharo-users-bounces(a)lists.pharo.org <mailto:pharo-users-bounces@lists.pharo.org> > en nombre de PBKResearch <peter(a)pbkresearch.co.uk <mailto:peter@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 that? I may try a few trials using it for real, rather than the test suite. Thanks again Peter Kenny From: Pharo-users <pharo-users-bounces(a)lists.pharo.org <mailto:pharo-users-bounces@lists.pharo.org> > On Behalf Of Matias Maretto Sent: 22 June 2018 22:54 To: Any question about pharo is welcome <pharo-users(a)lists.pharo.org <mailto:pharo-users@lists.pharo.org> > Subject: Re: [Pharo-users] OmniBase for Pharo 6 Hi Peter, yes I had the same error at the beginning. I have done 2 minor changes. Now it seems to be working fine (Although I am still running more tests). Here: ODBWin32FileStream >> closeHandle: aHandle "Close an open Win32 object handle, freeing any resources held by it. Once closed a handle is no longer valid. Answer whether the function succeeds. See Win32 SDK help for more information. BOOL CloseHandle( HANDLE hObject // handle of object to close );" "<apicall: ulong 'CloseHandle' (long) module:'kernel32.dll'>" ^ self ffiCall: #(ulong CloseHandle(long aHandle)) ODBWin32FileStream >> lockFile: aHandle offsetLow: loPos offsetHigh: hiPos lengthLow: loLength lengthHigh: hiLength "<apicall: long 'LockFile' (long ulong ulong ulong ulong) module: 'kernel32.dll'>" ^ self ffiCall: #(long LockFile #(long aHandle , ulong loPos , ulong hiPos , ulong loLength , ulong hiLength)) _____ De: Pharo-users <pharo-users-bounces(a)lists.pharo.org <mailto:pharo-users-bounces@lists.pharo.org> > en nombre de PBKResearch <peter(a)pbkresearch.co.uk <mailto:peter@pbkresearch.co.uk> > Enviado: viernes, 22 de junio de 2018 09:45 p. m. Para: 'Any question about pharo is welcome' Asunto: Re: [Pharo-users] OmniBase for Pharo 6 Matias I have just loaded Esteban's package in a new Pharo 6.1 under Windows 10. I get an error message saying 'File cannot be locked. Try again?'. When I select 'no', all tests are run and give red. Are you still running on win 7? If so, I must be doing something wrong. Can you give more details of the FFI corrections you made, please? Many thanks Peter Kenny From: Pharo-users <pharo-users-bounces(a)lists.pharo.org <mailto:pharo-users-bounces@lists.pharo.org> > On Behalf Of Matias Maretto Sent: 22 June 2018 21:07 To: Any question about pharo is welcome <pharo-users(a)lists.pharo.org <mailto:pharo-users@lists.pharo.org> > Subject: Re: [Pharo-users] OmniBase for Pharo 6 Esteban: it's working fine, I had to made a minor corrections on 2 FFI calls and now everithing seems to be working fine. For What I saw with Voyage-UnqLite only String Objects can be used to searilize; Omnibase allow to persist almost any kind of objects, thats the part I like about it. _____ De: Pharo-users <pharo-users-bounces(a)lists.pharo.org <mailto:pharo-users-bounces@lists.pharo.org> > en nombre de Esteban Lorenzano <estebanlm(a)gmail.com <mailto:estebanlm@gmail.com> > Enviado: jueves, 21 de junio de 2018 08:19 p. m. Para: Any question about pharo is welcome Asunto: Re: [Pharo-users] OmniBase for Pharo 6 I did it manually and I took like 5 min :P but this was really easy, just a bunch of FFI calls. Esteban > On 21 Jun 2018, at 15:31, Sean P. DeNigris <sean(a)clipperadams.com <mailto:sean@clipperadams.com> > wrote: > > EstebanLM wrote >> I just made a "blind port". migrated the old FFI to new UFFI > > Did you do this manually or use some migration tool? How long did it take? > > > > ----- > Cheers, > Sean > -- > Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html <http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html> Smalltalk - Pharo Smalltalk Users | Mailing List Archive forum.world.st Pharo Smalltalk Users forum and mailing list archive. Pharo User Forum >

June 23, 2018

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

by PBKResearch

Hi Alistair I am not trying to compare dates, I just want to be sure that OmniBase stores and retrieves dates without altering them. I have done further tests which show that this is not so. By looking at the start time, I find that the original date for today starts at 00:00:00 BST (as it should in London!), whereas after storing and retrieving by OmniBase it starts at 00:00:00 UTC (or GMT), i.e. it has shifted by an hour. This is not very important in itself, but it is worrying that OmniBase can change things. It may be a quirk of the way Date is handled by OmniBase, but it needs further investigation. I can see I shall have endless fun probing how OmniBase stores and retrieves instance variables - luckily I did not have anything major planned for the weekend! Or else I should just follow Todd's advice. Peter Kenny -----Original Message----- From: Pharo-users <pharo-users-bounces(a)lists.pharo.org> On Behalf Of Alistair Grant Sent: 23 June 2018 17:15 To: Pharo-Users <pharo-users(a)lists.pharo.org> Subject: Re: [Pharo-users] Strange Result - OmniBase bug or Date feature? Hi Peter, On Sat, 23 Jun 2018 at 17:47, PBKResearch <peter(a)pbkresearch.co.uk> wrote: > > 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? A Date in Pharo is a 24 hour period and thus the timezone is important, e.g. the start of 23 Jun in London is not the same as 23 Jun in Melbourne. If you want to compare the date using day / month / year and not as a 24 hour period, try using #equals: instead of #=. HTH, Alistair

June 23, 2018