OmniBase for Pharo 6

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
34 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Re: OmniBase for Pharo 6

Matias Maretto-2

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 <[hidden email]> en nombre de PBKResearch <[hidden email]>
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 <[hidden email]> On Behalf Of Matias Maretto
Sent: 22 June 2018 22:54
To: Any question about pharo is welcome <[hidden email]>
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 <[hidden email]> en nombre de PBKResearch <[hidden email]>
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 <[hidden email]> On Behalf Of Matias Maretto
Sent: 22 June 2018 21:07
To: Any question about pharo is welcome <[hidden email]>
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 <[hidden email]> en nombre de Esteban Lorenzano <[hidden email]>
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 <[hidden email]> 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

forum.world.st

Pharo Smalltalk Users forum and mailing list archive. Pharo User Forum



>

Reply | Threaded
Open this post in threaded view
|

Re: OmniBase for Pharo 6

Peter Kenny

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 <[hidden email]> On Behalf Of Matias Maretto
Sent: 23 June 2018 01:37
To: Any question about pharo is welcome <[hidden email]>
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 <[hidden email]> en nombre de PBKResearch <[hidden email]>
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 <[hidden email]> On Behalf Of Matias Maretto
Sent: 22 June 2018 22:54
To: Any question about pharo is welcome <[hidden email]>
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 <[hidden email]> en nombre de PBKResearch <[hidden email]>
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 <[hidden email]> On Behalf Of Matias Maretto
Sent: 22 June 2018 21:07
To: Any question about pharo is welcome <[hidden email]>
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 <[hidden email]> en nombre de Esteban Lorenzano <[hidden email]>
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 <[hidden email]> 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

forum.world.st

Pharo Smalltalk Users forum and mailing list archive. Pharo User Forum


>

Reply | Threaded
Open this post in threaded view
|

Re: OmniBase for Pharo 6

Peter Kenny

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 <[hidden email]> On Behalf Of PBKResearch
Sent: 23 June 2018 09:18
To: 'Any question about pharo is welcome' <[hidden email]>
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 <[hidden email]> On Behalf Of Matias Maretto
Sent: 23 June 2018 01:37
To: Any question about pharo is welcome <[hidden email]>
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 <[hidden email]> en nombre de PBKResearch <[hidden email]>
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 <[hidden email]> On Behalf Of Matias Maretto
Sent: 22 June 2018 22:54
To: Any question about pharo is welcome <[hidden email]>
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 <[hidden email]> en nombre de PBKResearch <[hidden email]>
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 <[hidden email]> On Behalf Of Matias Maretto
Sent: 22 June 2018 21:07
To: Any question about pharo is welcome <[hidden email]>
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 <[hidden email]> en nombre de Esteban Lorenzano <[hidden email]>
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 <[hidden email]> 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

forum.world.st

Pharo Smalltalk Users forum and mailing list archive. Pharo User Forum


>

Reply | Threaded
Open this post in threaded view
|

Re: OmniBase for Pharo 6

Matias Maretto-2

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 <[hidden email]> en nombre de PBKResearch <[hidden email]>
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 <[hidden email]> On Behalf Of PBKResearch
Sent: 23 June 2018 09:18
To: 'Any question about pharo is welcome' <[hidden email]>
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 <[hidden email]> On Behalf Of Matias Maretto
Sent: 23 June 2018 01:37
To: Any question about pharo is welcome <[hidden email]>
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 <[hidden email]> en nombre de PBKResearch <[hidden email]>
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 <[hidden email]> On Behalf Of Matias Maretto
Sent: 22 June 2018 22:54
To: Any question about pharo is welcome <[hidden email]>
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 <[hidden email]> en nombre de PBKResearch <[hidden email]>
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 <[hidden email]> On Behalf Of Matias Maretto
Sent: 22 June 2018 21:07
To: Any question about pharo is welcome <[hidden email]>
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 <[hidden email]> en nombre de Esteban Lorenzano <[hidden email]>
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 <[hidden email]> 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

forum.world.st

Pharo Smalltalk Users forum and mailing list archive. Pharo User Forum



>

Reply | Threaded
Open this post in threaded view
|

Re: OmniBase for Pharo 6

Peter Kenny

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 <[hidden email]> On Behalf Of Matias Maretto
Sent: 23 June 2018 19:40
To: Any question about pharo is welcome <[hidden email]>
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 <[hidden email]> en nombre de PBKResearch <[hidden email]>
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 <[hidden email]> On Behalf Of PBKResearch
Sent: 23 June 2018 09:18
To: 'Any question about pharo is welcome' <[hidden email]>
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 <[hidden email]> On Behalf Of Matias Maretto
Sent: 23 June 2018 01:37
To: Any question about pharo is welcome <[hidden email]>
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 <[hidden email]> en nombre de PBKResearch <[hidden email]>
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 <[hidden email]> On Behalf Of Matias Maretto
Sent: 22 June 2018 22:54
To: Any question about pharo is welcome <[hidden email]>
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 <[hidden email]> en nombre de PBKResearch <[hidden email]>
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 <[hidden email]> On Behalf Of Matias Maretto
Sent: 22 June 2018 21:07
To: Any question about pharo is welcome <[hidden email]>
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 <[hidden email]> en nombre de Esteban Lorenzano <[hidden email]>
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 <[hidden email]> 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

forum.world.st

Pharo Smalltalk Users forum and mailing list archive. Pharo User Forum


>

Reply | Threaded
Open this post in threaded view
|

Re: OmniBase for Pharo 6

Matias Maretto-2

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 <[hidden email]> en nombre de PBKResearch <[hidden email]>
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 <[hidden email]> On Behalf Of Matias Maretto
Sent: 23 June 2018 19:40
To: Any question about pharo is welcome <[hidden email]>
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 <[hidden email]> en nombre de PBKResearch <[hidden email]>
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 <[hidden email]> On Behalf Of PBKResearch
Sent: 23 June 2018 09:18
To: 'Any question about pharo is welcome' <[hidden email]>
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 <[hidden email]> On Behalf Of Matias Maretto
Sent: 23 June 2018 01:37
To: Any question about pharo is welcome <[hidden email]>
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 <[hidden email]> en nombre de PBKResearch <[hidden email]>
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 <[hidden email]> On Behalf Of Matias Maretto
Sent: 22 June 2018 22:54
To: Any question about pharo is welcome <[hidden email]>
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 <[hidden email]> en nombre de PBKResearch <[hidden email]>
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 <[hidden email]> On Behalf Of Matias Maretto
Sent: 22 June 2018 21:07
To: Any question about pharo is welcome <[hidden email]>
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 <[hidden email]> en nombre de Esteban Lorenzano <[hidden email]>
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 <[hidden email]> 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

forum.world.st

Pharo Smalltalk Users forum and mailing list archive. Pharo User Forum



>

Reply | Threaded
Open this post in threaded view
|

Re: OmniBase for Pharo 6

Peter Kenny

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 <[hidden email]> On Behalf Of Matias Maretto
Sent: 24 June 2018 23:33
To: Any question about pharo is welcome <[hidden email]>
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 <[hidden email]> en nombre de PBKResearch <[hidden email]>
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 <[hidden email]> On Behalf Of Matias Maretto
Sent: 23 June 2018 19:40
To: Any question about pharo is welcome <[hidden email]>
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 <[hidden email]> en nombre de PBKResearch <[hidden email]>
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 <[hidden email]> On Behalf Of PBKResearch
Sent: 23 June 2018 09:18
To: 'Any question about pharo is welcome' <[hidden email]>
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 <[hidden email]> On Behalf Of Matias Maretto
Sent: 23 June 2018 01:37
To: Any question about pharo is welcome <[hidden email]>
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 <[hidden email]> en nombre de PBKResearch <[hidden email]>
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 <[hidden email]> On Behalf Of Matias Maretto
Sent: 22 June 2018 22:54
To: Any question about pharo is welcome <[hidden email]>
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 <[hidden email]> en nombre de PBKResearch <[hidden email]>
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 <[hidden email]> On Behalf Of Matias Maretto
Sent: 22 June 2018 21:07
To: Any question about pharo is welcome <[hidden email]>
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 <[hidden email]> en nombre de Esteban Lorenzano <[hidden email]>
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 <[hidden email]> 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

forum.world.st

Pharo Smalltalk Users forum and mailing list archive. Pharo User Forum


>

Reply | Threaded
Open this post in threaded view
|

Re: OmniBase for Pharo 6

tblanchard
In reply to this post by Matias Maretto-2
I will just add that the failures I was experiencing involved storing "documents" with deep hierarchies of heterogeneous items.  Something along the lines of EMR's (electronic medical records - which if you have any experience in that domain - are very complex).

The failures would manifest as randomly thrown exceptions while trying to read a particularly large and complex hierarchy - which would result in documents missing segments when rendered.  Rescuing the data took a couple weeks of constantly trying to read smaller chunks and retrying when exceptions were thrown.

So I would include tests along those lines before trusting it with important data.  The database I was working with was quite large when reads began to fail.

On Jun 24, 2018, at 3:33 PM, Matias Maretto <[hidden email]> wrote:

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 <[hidden email]> en nombre de PBKResearch <[hidden email]>
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 <[hidden email]> On Behalf Of Matias Maretto
Sent: 23 June 2018 19:40
To: Any question about pharo is welcome <[hidden email]>
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 <[hidden email]> en nombre de PBKResearch <[hidden email]>
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 <[hidden email]> On Behalf Of PBKResearch
Sent: 23 June 2018 09:18
To: 'Any question about pharo is welcome' <[hidden email]>
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 <[hidden email]> On Behalf Of Matias Maretto
Sent: 23 June 2018 01:37
To: Any question about pharo is welcome <[hidden email]>
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 <[hidden email]> en nombre de PBKResearch <[hidden email]>
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 <[hidden email]> On Behalf Of Matias Maretto
Sent: 22 June 2018 22:54
To: Any question about pharo is welcome <[hidden email]>
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 <[hidden email]> en nombre de PBKResearch <[hidden email]>
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 <[hidden email]> On Behalf Of Matias Maretto
Sent: 22 June 2018 21:07
To: Any question about pharo is welcome <[hidden email]>
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 <[hidden email]> en nombre de Esteban Lorenzano <[hidden email]>
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 <[hidden email]> 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

Pharo Smalltalk Users forum and mailing list archive. Pharo User Forum


> 


Reply | Threaded
Open this post in threaded view
|

Re: OmniBase for Pharo 6

Peter Kenny

Todd

 

Many thanks for these useful pointers – I had thought of asking you for a hint of where problems can occur, but you beat me to it. At present I am just playing, to get the feel of what it can do, but when it gets to real data I will consider defensive measures – backups and change logs, for example.

 

The application I am considering involves reading and storing quite large documents, which are input as XML. Presumably it would be safer to store the XML in the database. Similarly, with other complex objects, we could consider a hybrid system in which objects are serialized with some other mechanism, e.g. STON, and OmniBase is just used to store and manage them. All speculation until we try it out.

 

Thanks again

 

Peter Kenny

 

From: Pharo-users <[hidden email]> On Behalf Of Todd Blanchard
Sent: 25 June 2018 07:31
To: Any question about pharo is welcome <[hidden email]>
Subject: Re: [Pharo-users] OmniBase for Pharo 6

 

I will just add that the failures I was experiencing involved storing "documents" with deep hierarchies of heterogeneous items.  Something along the lines of EMR's (electronic medical records - which if you have any experience in that domain - are very complex).

 

The failures would manifest as randomly thrown exceptions while trying to read a particularly large and complex hierarchy - which would result in documents missing segments when rendered.  Rescuing the data took a couple weeks of constantly trying to read smaller chunks and retrying when exceptions were thrown.

 

So I would include tests along those lines before trusting it with important data.  The database I was working with was quite large when reads began to fail.

 

On Jun 24, 2018, at 3:33 PM, Matias Maretto <[hidden email]> wrote:

 

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 <[hidden email]> en nombre de PBKResearch <[hidden email]>
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 <[hidden email]> On Behalf Of Matias Maretto
Sent: 23 June 2018 19:40
To: Any question about pharo is welcome <[hidden email]>
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 <[hidden email]> en nombre de PBKResearch <[hidden email]>
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 <[hidden email]> On Behalf Of PBKResearch
Sent: 23 June 2018 09:18
To: 'Any question about pharo is welcome' <[hidden email]>
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 <[hidden email]> On Behalf Of Matias Maretto
Sent: 23 June 2018 01:37
To: Any question about pharo is welcome <[hidden email]>
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 <[hidden email]> en nombre de PBKResearch <[hidden email]>
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 <[hidden email]> On Behalf Of Matias Maretto
Sent: 22 June 2018 22:54
To: Any question about pharo is welcome <[hidden email]>
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 <[hidden email]> en nombre de PBKResearch <[hidden email]>
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 <[hidden email]> On Behalf Of Matias Maretto
Sent: 22 June 2018 21:07
To: Any question about pharo is welcome <[hidden email]>
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 <[hidden email]> en nombre de Esteban Lorenzano <[hidden email]>
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 <[hidden email]> 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

Pharo Smalltalk Users forum and mailing list archive. Pharo User Forum


> 

 

Reply | Threaded
Open this post in threaded view
|

Re: OmniBase for Pharo 6

marco
In reply to this post by Matias Maretto-2
One serious problem left: OmniBaseTest>>testGC fails.

Have a look at the 2 methods

/ODBContainer>>lockDataFile
"Dec, 2010 sas: this code was relying in evaluating a block that was
happening only in win32
    but not in *nix. So now I'm making it wait for the lock and then execute
the code normally
    because it seems the intention was the same."
    | currentSpace defaultSpace |

    activeDataFile waitForAddingLock.
    currentSpace := activeDataFile == dataFileA ifTrue: [0] ifFalse: [1].
    defaultSpace := objectManager defaultObjectSpace.
    currentSpace == defaultSpace
        ifFalse:
            [defaultSpace == 0
                ifTrue:
                    [dataFileA isNil ifTrue: [dataFileA := ODBObjectStorage
openOn: self dataFileNameA].
                    activeDataFile := dataFileA]
                ifFalse:
                    [dataFileB isNil ifTrue: [dataFileB := ODBObjectStorage
openOn: self dataFileNameB].
                    activeDataFile := dataFileB].
            ^self lockDataFile]


ODBFile>>waitForLockAt: pos length: length whileWaitingDo: aBlock
        "Wait for lock at given position.
        Evaluate aBlock in each iteration."

    "Dec, 2010. sas: evaluating code in each iteration while waiting sounds
weird but whatever.
    I think this was designed on the wrong assumption that the OS always
will provide a false
    in the first try but what actually happens is that in win32 you always
will
    get at least one false but in *nixes you don't do see that happening
(which is totally reasonable).
    BEWARE of stupid code relying on this stupid assumption (I've already
patched #lockDataFile because of this)."
   
    | startTime currentTime |
    (stream lockAt: pos length: length) ifFalse: [
        startTime := Time totalSeconds.
        [stream lockAt: pos length: length] whileFalse: [
            aBlock value.
            currentTime := Time totalSeconds.
            currentTime - startTime < self timeOutLength
                ifFalse: [
                    ODBLockNotification signal
                        ifTrue: [startTime := currentTime]
                        ifFalse: [^ODBCannotLock signal]]]]
/

So "sas" did a refactoring in 2010 because he/she thought it is stupid code.
This code change breaks the GarbageCollection of Omnibase.

I reverted the first method to the original code of the Omnibase author,
David Gorisek:

/lockDataFile

    | currentSpace defaultSpace |

    activeDataFile waitForAddingLockWhileWaitingDo:
    [currentSpace := activeDataFile == dataFileA ifTrue: [0] ifFalse: [1].
    defaultSpace := objectManager defaultObjectSpace.
    currentSpace == defaultSpace
        ifFalse:
            [defaultSpace == 0
                ifTrue:
                    [dataFileA isNil ifTrue: [dataFileA := ODBObjectStorage
openOn: self dataFileNameA].
                    activeDataFile := dataFileA]
                ifFalse:
                    [dataFileB isNil ifTrue: [dataFileB := ODBObjectStorage
openOn: self dataFileNameB].
                    activeDataFile := dataFileB].
            ^self lockDataFile]]
/
I removed the comment of "sas" from the second method. It is wrong.


The garbage collection works again and the test is green. GC is an important
feature of Omnibase.
It creates a new repository/database file and copies the data into the new
file, compressing the data.
It keeps your database compact and clean. If you don't run it (frequently)
your db files keep on growing...  

Matias, your fixes are absolutely valid and should be published - together
with the one above -  in Esteban's repository.




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

Reply | Threaded
Open this post in threaded view
|

Re: OmniBase for Pharo 6

Matias Maretto-2

Marco: thank you for this. A few weeks ago when I was trying to find the "lock" problem I saw this method but I did not dare to change it; and just as you said I  been using OminBase with no problem, but never runned the Garbage Collector, Surely I was going to have a bigger problem in the future for not running the garbageCollect. 

I have just update this method on my project and tried both the garbageCollect and the reorganize method , both worked fine (win 7 32bits, later I am going to test on Win 10 64 bits).

Thanks again.

Matías.




De: Pharo-users <[hidden email]> en nombre de marco <[hidden email]>
Enviado: miércoles, 25 de julio de 2018 10:23 a. m.
Para: [hidden email]
Asunto: Re: [Pharo-users] OmniBase for Pharo 6
 
One serious problem left: OmniBaseTest>>testGC fails.

Have a look at the 2 methods

/ODBContainer>>lockDataFile
"Dec, 2010 sas: this code was relying in evaluating a block that was
happening only in win32
    but not in *nix. So now I'm making it wait for the lock and then execute
the code normally
    because it seems the intention was the same."
    | currentSpace defaultSpace |

    activeDataFile waitForAddingLock.
    currentSpace := activeDataFile == dataFileA ifTrue: [0] ifFalse: [1].
    defaultSpace := objectManager defaultObjectSpace.
    currentSpace == defaultSpace
        ifFalse:
            [defaultSpace == 0
                ifTrue:
                    [dataFileA isNil ifTrue: [dataFileA := ODBObjectStorage
openOn: self dataFileNameA].
                    activeDataFile := dataFileA]
                ifFalse:
                    [dataFileB isNil ifTrue: [dataFileB := ODBObjectStorage
openOn: self dataFileNameB].
                    activeDataFile := dataFileB].
            ^self lockDataFile]


ODBFile>>waitForLockAt: pos length: length whileWaitingDo: aBlock
        "Wait for lock at given position.
        Evaluate aBlock in each iteration."

    "Dec, 2010. sas: evaluating code in each iteration while waiting sounds
weird but whatever.
    I think this was designed on the wrong assumption that the OS always
will provide a false
    in the first try but what actually happens is that in win32 you always
will
    get at least one false but in *nixes you don't do see that happening
(which is totally reasonable).
    BEWARE of stupid code relying on this stupid assumption (I've already
patched #lockDataFile because of this)."
  
    | startTime currentTime |
    (stream lockAt: pos length: length) ifFalse: [
        startTime := Time totalSeconds.
        [stream lockAt: pos length: length] whileFalse: [
            aBlock value.
            currentTime := Time totalSeconds.
            currentTime - startTime < self timeOutLength
                ifFalse: [
                    ODBLockNotification signal
                        ifTrue: [startTime := currentTime]
                        ifFalse: [^ODBCannotLock signal]]]]
/

So "sas" did a refactoring in 2010 because he/she thought it is stupid code.
This code change breaks the GarbageCollection of Omnibase.

I reverted the first method to the original code of the Omnibase author,
David Gorisek:

/lockDataFile

    | currentSpace defaultSpace |

    activeDataFile waitForAddingLockWhileWaitingDo:
    [currentSpace := activeDataFile == dataFileA ifTrue: [0] ifFalse: [1].
    defaultSpace := objectManager defaultObjectSpace.
    currentSpace == defaultSpace
        ifFalse:
            [defaultSpace == 0
                ifTrue:
                    [dataFileA isNil ifTrue: [dataFileA := ODBObjectStorage
openOn: self dataFileNameA].
                    activeDataFile := dataFileA]
                ifFalse:
                    [dataFileB isNil ifTrue: [dataFileB := ODBObjectStorage
openOn: self dataFileNameB].
                    activeDataFile := dataFileB].
            ^self lockDataFile]]
/
I removed the comment of "sas" from the second method. It is wrong.


The garbage collection works again and the test is green. GC is an important
feature of Omnibase.
It creates a new repository/database file and copies the data into the new
file, compressing the data.
It keeps your database compact and clean. If you don't run it (frequently)
your db files keep on growing... 

Matias, your fixes are absolutely valid and should be published - together
with the one above -  in Esteban's repository.




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



Reply | Threaded
Open this post in threaded view
|

Re: OmniBase for Pharo 6

Peter Kenny

Marco

 

Thanks for this. Just for curiosity, did you test it just on Windows, or on other OSs as well. The logic of the Dec 2010 fix was that David Gorisek’s original, being developed on Dolphin, could not be guaranteed to work except on Windows. I only use Windows, so it is just curiosity.

 

BTW, the author of the Dec 2010 fix, ‘sas’, is Sebastian Sastre, so definitely ‘he’.

 

Peter Kenny

 

 

From: Pharo-users <[hidden email]> On Behalf Of Matias Maretto
Sent: 25 July 2018 13:34
To: Any question about pharo is welcome <[hidden email]>
Subject: Re: [Pharo-users] OmniBase for Pharo 6

 

Marco: thank you for this. A few weeks ago when I was trying to find the "lock" problem I saw this method but I did not dare to change it; and just as you said I  been using OminBase with no problem, but never runned the Garbage Collector, Surely I was going to have a bigger problem in the future for not running the garbageCollect. 

 

I have just update this method on my project and tried both the garbageCollect and the reorganize method , both worked fine (win 7 32bits, later I am going to test on Win 10 64 bits).

 

Thanks again.

 

Matías.

 

 


De: Pharo-users <[hidden email]> en nombre de marco <[hidden email]>
Enviado: miércoles, 25 de julio de 2018 10:23 a. m.
Para: [hidden email]
Asunto: Re: [Pharo-users] OmniBase for Pharo 6

 

One serious problem left: OmniBaseTest>>testGC fails.

Have a look at the 2 methods

/ODBContainer>>lockDataFile
"Dec, 2010 sas: this code was relying in evaluating a block that was
happening only in win32
    but not in *nix. So now I'm making it wait for the lock and then execute
the code normally
    because it seems the intention was the same."
    | currentSpace defaultSpace |

    activeDataFile waitForAddingLock.
    currentSpace := activeDataFile == dataFileA ifTrue: [0] ifFalse: [1].
    defaultSpace := objectManager defaultObjectSpace.
    currentSpace == defaultSpace
        ifFalse:
            [defaultSpace == 0
                ifTrue:
                    [dataFileA isNil ifTrue: [dataFileA := ODBObjectStorage
openOn: self dataFileNameA].
                    activeDataFile := dataFileA]
                ifFalse:
                    [dataFileB isNil ifTrue: [dataFileB := ODBObjectStorage
openOn: self dataFileNameB].
                    activeDataFile := dataFileB].
            ^self lockDataFile]


ODBFile>>waitForLockAt: pos length: length whileWaitingDo: aBlock
        "Wait for lock at given position.
        Evaluate aBlock in each iteration."

    "Dec, 2010. sas: evaluating code in each iteration while waiting sounds
weird but whatever.
    I think this was designed on the wrong assumption that the OS always
will provide a false
    in the first try but what actually happens is that in win32 you always
will
    get at least one false but in *nixes you don't do see that happening
(which is totally reasonable).
    BEWARE of stupid code relying on this stupid assumption (I've already
patched #lockDataFile because of this)."
  
    | startTime currentTime |
    (stream lockAt: pos length: length) ifFalse: [
        startTime := Time totalSeconds.
        [stream lockAt: pos length: length] whileFalse: [
            aBlock value.
            currentTime := Time totalSeconds.
            currentTime - startTime < self timeOutLength
                ifFalse: [
                    ODBLockNotification signal
                        ifTrue: [startTime := currentTime]
                        ifFalse: [^ODBCannotLock signal]]]]
/

So "sas" did a refactoring in 2010 because he/she thought it is stupid code.
This code change breaks the GarbageCollection of Omnibase.

I reverted the first method to the original code of the Omnibase author,
David Gorisek:

/lockDataFile

    | currentSpace defaultSpace |

    activeDataFile waitForAddingLockWhileWaitingDo:
    [currentSpace := activeDataFile == dataFileA ifTrue: [0] ifFalse: [1].
    defaultSpace := objectManager defaultObjectSpace.
    currentSpace == defaultSpace
        ifFalse:
            [defaultSpace == 0
                ifTrue:
                    [dataFileA isNil ifTrue: [dataFileA := ODBObjectStorage
openOn: self dataFileNameA].
                    activeDataFile := dataFileA]
                ifFalse:
                    [dataFileB isNil ifTrue: [dataFileB := ODBObjectStorage
openOn: self dataFileNameB].
                    activeDataFile := dataFileB].
            ^self lockDataFile]]
/
I removed the comment of "sas" from the second method. It is wrong.


The garbage collection works again and the test is green. GC is an important
feature of Omnibase.
It creates a new repository/database file and copies the data into the new
file, compressing the data.
It keeps your database compact and clean. If you don't run it (frequently)
your db files keep on growing... 

Matias, your fixes are absolutely valid and should be published - together
with the one above -  in Esteban's repository.




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

forum.world.st

Pharo Smalltalk Users forum and mailing list archive. Pharo User Forum



Reply | Threaded
Open this post in threaded view
|

Re: OmniBase for Pharo 6

marco
Peter,

yes, tested windows (10) and unix/linux (32-bit). It works, green light.

With the 2010 "fix" at least the garbage collection will not work on any OS.
The logic tries to lock the same file twice.




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

Reply | Threaded
Open this post in threaded view
|

Re: OmniBase for Pharo 6

Peter Kenny
Marco

Thanks again. I was apprehensive about using OmniBase for real. With all
green tests I am much happier.

Peter Kenny

-----Original Message-----
From: Pharo-users <[hidden email]> On Behalf Of marco
Sent: 27 July 2018 14:51
To: [hidden email]
Subject: Re: [Pharo-users] OmniBase for Pharo 6

Peter,

yes, tested windows (10) and unix/linux (32-bit). It works, green light.

With the 2010 "fix" at least the garbage collection will not work on any OS.

The logic tries to lock the same file twice.




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


12