[Glass] GsFile atEnd answering nil rather than boolean
Locked
[Glass] GsFile atEnd answering nil rather than boolean
 
|
Hi guys,
I am trying to import a large SIXX file (46MB) using an approach like the following: | codec stream object context persistentKey persistentDict | persistentKey := ('SIXX_ROOT_ARRAY', Object new identityHash asString) asSymbol. persistentDict := UserGlobals at: #LargeSIXXExportsAndImportRoots. stream := (FileStream oldFileNamed: aFilename) text. [ MCPlatformSupport commitOnAlmostOutOfMemoryDuring: [ persistentDict at: persistentKey put: Array new. context := SixxContext forRead. FACompatibilityUtils current addSixxShapeChargers: context classResolver. object := Object readSixxFrom: stream context: context persistentRoot: (persistentDict at: persistentKey) ]. ] ensure: [ persistentDict removeKey: persistentKey ]. ^ object The problem is that I get a Sixx parse error because at some point GsFile answers nil to #atEnd. The method says that that happens when there is an error. But I have no idea what error can be. I tried to send #lastErrorString to the GsFile instance but I also get nil. Any clues on when #atEnd can answer nil or how can I get more info of why it is failing? Thanks in advance, _______________________________________________ Glass mailing list [hidden email] http://lists.gemtalksystems.com/mailman/listinfo/glass |
Re: [Glass] GsFile atEnd answering nil rather than boolean
|
|
What is funny is that there is a class called BinaryOrTextFile which I have no clue what it is (no class comment and doesn't appear in guides either), but it's a subclass of GsFile and implements: atEnd | ans | (ans := super atEnd) == nil ifTrue: [ ^true ]. ^ans So...it is assuming that GsFile atEnd answering nil is like true.... while superclass (GsFile) #atEnd method comment says the primitive answers nil upon error. Best, On Wed, Mar 4, 2015 at 10:08 AM, Mariano Martinez Peck <[hidden email]> wrote:
_______________________________________________ Glass mailing list [hidden email] http://lists.gemtalksystems.com/mailman/listinfo/glass |
Re: [Glass] GsFile atEnd answering nil rather than boolean
|
|
In reply to this post by GLASS mailing list
On Mar 4, 2015, at 5:08 AM, Mariano Martinez Peck via Glass <[hidden email]> wrote:
Was the GsFile instance opened on the client or on the server? This is a common pattern: (flag := aGsFile atEnd) ifNil: [self error: gsFile serverErrorString]. James _______________________________________________ Glass mailing list [hidden email] http://lists.gemtalksystems.com/mailman/listinfo/glass |
Re: [Glass] GsFile atEnd answering nil rather than boolean
|
|
On Wed, Mar 4, 2015 at 12:22 PM, Mariano Martinez Peck <[hidden email]> wrote:
_______________________________________________ Glass mailing list [hidden email] http://lists.gemtalksystems.com/mailman/listinfo/glass |
Re: [Glass] GsFile atEnd answering nil rather than boolean
|
|
In reply to this post by GLASS mailing list
Mariano,
This looks like a bug and I've created an issue for it[1]. I've proposed a fix in the bug report ... I think it is correct for 3.1.0.6, but it will have to be validated for 2.4.x and 3.2.x .... Dale [1] https://github.com/GsDevKit/GsDevKit/issues/58 On 03/04/2015 05:08 AM, Mariano
Martinez Peck via Glass wrote:
_______________________________________________ Glass mailing list [hidden email] http://lists.gemtalksystems.com/mailman/listinfo/glass |
Re: [Glass] GsFile atEnd answering nil rather than boolean
|
|
In reply to this post by GLASS mailing list
On 03/04/2015 05:13 AM, Mariano
Martinez Peck via Glass wrote:
I think that BinaryOrTextFile was implemented to fill the missing gap for FileStream and dates from the very early days of GLASS (8 years ago?). Historically GemStone has returned nil instead of raising errors for GsFile and friends which has made writing porting code from Squeak/Pharo somewhat dicey, since you have to look at each Smalltalk call and test for nil .... FileStream is a more recent addition and is obviously missing test coverage ... help in this area would be appreciated ... I have never said no to code improvement contributions:) I just haven't gotten that many over the years:( Dale _______________________________________________ Glass mailing list [hidden email] http://lists.gemtalksystems.com/mailman/listinfo/glass |
Re: [Glass] GsFile atEnd answering nil rather than boolean
|
|
In reply to this post by GLASS mailing list
On Wed, Mar 4, 2015 at 4:03 PM, Dale Henrichs via Glass <[hidden email]> wrote:
Hi Dale, Thanks for opening the issue. After some more time and research, I think the reason why I may have received the nil was because my GsFile become persisted and probably flushed away by the VM causing the loss of the session state (GbsRtErrLostSessionState). But...I discovered that a lot later...so probably reporting the error when getting the nil at #atEnd makes sense as you put in the ticker and as James suggested. BTW...are GemStone issues now handled in GsDevKit issue tracker or you also use your internal bug tracker? Thanks
_______________________________________________ Glass mailing list [hidden email] http://lists.gemtalksystems.com/mailman/listinfo/glass |
Re: [Glass] GsFile atEnd answering nil rather than boolean
|
|
On 03/05/2015 05:49 AM, Mariano
Martinez Peck wrote:
The open source GsDevKit issues are handled in the GsDevKit/GsDevKit issue tracker on GitHub (each open source GitHub project project has it's own issue tracker) ... I will eventually move glassdb/glass to GsDevKit/GsDevKit, but that will take a fair amount of work to pull off and I've got my hands full as it is ... Bugs against the base GemStone are handled by out internal bug tracker ... the internal bug tracker is not externally visible other than through bugnotes. The internal tracker is only used for tracking changes that need to be made to the base product ... In practice, it is possible to patch Smalltalk bugs in the base by using code in GLASS/GsDevKit, so internal bugs are usually only filed for those problems in the c-code ... Anyone is free to submit pull requests against the open source projects as that code is actually supposed to be maintained by the community ... in practice it seems that everyone waits for me to fix bugs... Dale _______________________________________________ Glass mailing list [hidden email] http://lists.gemtalksystems.com/mailman/listinfo/glass |
«
Return to GLASS
|
1 view|%1 views
| Free forum by Nabble | Edit this page |