search

GsDevKit / GsDevKit_home

master GsDevKit project
http://gsdevkit.github.io/GsDevKit_home
MIT License
31 stars 36 forks source link

Update smalltalkCI-related code #195

Open fniephaus opened 6 years ago

fniephaus commented 6 years ago

smalltalkCI still provides compatibility for the current version of GsDevKit. Nonetheless, it would be great if we could update some related code (e.g. this). Same is true for GsDevKit_todeClient (e.g. here). Which other projects rely on smalltalkCI's internal API?

I wonder if it would be possible to move some of this code into the smalltalkCI repository and call it from GsDevKit_home or GsDevKit_todeClient. That would make it easier to keep everything in sync and then both projects would rely on smalltalkCI's files rather than on smalltalkCI's internal API.

dalehenrich commented 6 years ago

I will have to research this, because I don't remember offhand why it was required ... at the time ... may be a week or so before I have the cycles, but SmalltalkCI is always near the top:)

dalehenrich commented 6 years ago

Okay, I'm looking at this now and I think I understand the problem with SmalltalkCI platformClass basicNew.

With regards to "projects relying smalltalkCI's internal API" I've pretty much tried to limit the SmalltalkCI leakage to GsDevKit_home by providing scripts that do all of the dirty work. The todeClient project (encapsulated by GsDevKit_home) provides a command-line-based API that uses the .smalltalk.ston spec to load code into a stone and to setup run-time options is a stone ... just like they are used to run GemStone tests ... and unless I'm mistaken the access to SmalltalkCI is limited to these methods and these two chunks of script code: here and here --- where both of these chunks are leveraging the SCIGemStoneServerConfigSpec.

But I'm not sure I understand the problem with GsDevKit_todeClient ... you gave a pretty broad range of lines a lot of which I don't think is related to SmalltalkCI other than this range and even then, I'm not sure what you have to complain about there ... I'm using class-side protocol that if it is technically private, I'm not exactly sure what you would be proposing for a "public api" in this case ...

So please explain to me how GsDevKit_todeClient is using smalltalkCI's internal API in these three places: 1, 2, and 3; and what you have in mind for a better public API? ...

now Point 2 is using SmalltalkCI platformClass basicNew because I want to read the .smalltalk.ston file and get access to the spec information ... so this would be a nice addition to the public SmalltalkCI API --- if there isn't already an alternative

fniephaus commented 6 years ago

GsDevKit_todeClient is definitely not as heavily using smalltalkCI API, if I'm complaining it's mostly this range and that range, but we can leave it as is for now. My main problem is that I only know that several GsDevKit-related repositories use smalltalkCI API and I always need to check all of them to see what is used and how. If all this smalltalkCI-related code could eventually end up in one repo, that'd make things easier.

Re point 2: I'd like to get rid of readSTONSpec: as some point, especially because of the side effect. If you want to read a SmalltalkCISpec, why not use its fromStream: method? BTW: I'm about to add a fromFile: aFilename soon too.

dalehenrich commented 6 years ago

I assume that at the time I wrote this code, the class side methods would unconditionally launch tests or there were other unwanted side effects ... if there are equivalent methods then it will be easy enough to incorporate fixes ... at the end of the day I think that the GsDevKit_home travis tests are sufficient to exercise the uses of SmalltalkCI except for the multiple client feature -- but that is covered by SmalltalkCI tests ... other projects use GsDevKit_home APIs and clients that are built using the GsDevKit_home scripts ... when I have time to come back to this I will study the SmalltalkCI API a bit and then may have questions about details ...