These are chat archives for dalehenrich/chat

13th
Apr 2016
Fabio Niephaus
@fniephaus
Apr 13 2016 14:12
are you online?
Dale Henrichs
@dalehenrich
Apr 13 2016 16:11
I am now ...
Fabio Niephaus
@fniephaus
Apr 13 2016 16:12
hi, I've been working on this:
hpi-swa/smalltalkCI#130
And I had problems with GemStone, but I think I got it. I had to delete the cache and I don't really know why
Dale Henrichs
@dalehenrich
Apr 13 2016 16:16
I would be interested in knowing what troubles you were having ... stack or log file would be nice ... if you had "troubles" it's possible that other folks would have trouble as well and if I can nip a problem in the bud, I want to :)
Fabio Niephaus
@fniephaus
Apr 13 2016 16:20
I'm sure it would work if I had deleted the caches
I also wanted to point you to this change: hpi-swa/smalltalkCI@b01b21e
especially classesToTest.st and classesToTestFrom..st
Dale Henrichs
@dalehenrich
Apr 13 2016 16:28
Thanks! Yes that occurs because you were using a cache from an older version of GsDevKit_home with a new version of SmalltalkCI and the reason for my comment ... the old version of GsDevKit_home would work with a new version of smalltalkCI, but a the new version of GsDevKit_home does not work with an older cache ...
Fabio Niephaus
@fniephaus
Apr 13 2016 16:29
Haven't had the time to read and parse your comment, but yes, that makes sense and we should find a way to deal with this
BTW: is there a TestCoverage class in GemStone? Making coverage tests available for Pharo should be relatively simple, I'm wondering how hard it would be in GemStone
Dale Henrichs
@dalehenrich
Apr 13 2016 16:34
why are you moving that method to the class side? The senders are on the instance side and calling with self and the super method is on the instance side as well ...
Are you saying that you are moving all of those methods and that entire collection of methods to the class-side for SmalltalkCI in general?
Fabio Niephaus
@fniephaus
Apr 13 2016 16:35
yes, I've already done that, because then those functions are reusable and we happened to need them for coverage testing
sorry, i should have mentioned that before
Dale Henrichs
@dalehenrich
Apr 13 2016 16:38
... okay, then you don't need to check with me :) I obviously had no idea what you were doing and in isolation the move makes no sense ... I assume you checked for senders and everything ... In my other code I'm just as likely to be sending #classesToTest to an instance of smalltalkCI :) ... but in this case I don't think I'm using it anywhere else :)
Fabio Niephaus
@fniephaus
Apr 13 2016 16:39
Ok, just wanted to make sure :)
Also, you have implemented #'*' : [], for #testing. is that actually been used already?
Dale Henrichs
@dalehenrich
Apr 13 2016 16:42
I used it when I blew out the log for the Seaside test ... in fact it was for Seaside that I added the particular feature ... I'm not married to the name or implementation, but I do want to be able to say "run every test case in the image"
Fabio Niephaus
@fniephaus
Apr 13 2016 16:43
the use case is absolutely valid, I was just surprised by the naming. wouldn't it be better to just use something like #runAllTests : True
Dale Henrichs
@dalehenrich
Apr 13 2016 16:45
I've never claimed to be good at naming ... you can change it to whatever you'd like and I'll update the config file for Seaside :)
Fabio Niephaus
@fniephaus
Apr 13 2016 16:45
haha all good
thanks, Dale!
BTW: I will definitely be at ESUG
Dale Henrichs
@dalehenrich
Apr 13 2016 16:46
Excellent it will be good to meet you!
Fabio Niephaus
@fniephaus
Apr 13 2016 16:46
Looking forward to meeting you!
Fabio Niephaus
@fniephaus
Apr 13 2016 16:52
while you are still here: Could you explain again, why the changes to pharo are impacting gemstone? I mean the zeroconf change
Dale Henrichs
@dalehenrich
Apr 13 2016 19:24
gemstone was using the old way of cachining ... using zeroconf and stashing the image and changes file in the _cache directory ... you are no longer using zeroconf and you are stashing zip files ... the intent of the gemstone code was to share the client cache not invent my own caching for the client code ...
so I want the gemstone code to use the "standard smalltalkCI" technique for downloading and caching client artifacts (eventually I assume that there will be Squeak clients as well) ... and I prefer not to invent and maintain an independent caching scheme if you are zipping the client/image/sources file, I want to use the zipped versions of the client/image/sources files if they exist or create them if they do not ...
Fabio Niephaus
@fniephaus
Apr 13 2016 20:52
Understood! The zeroconf scripts do download zips and then extract them which is why I got rid of them. smalltalkCI can download the zip straight to cache and then extract from there, no need to extract and compress back and forth which is IO heavy for Travis
Let's work on this in hpi-swa/smalltalkCI#127
Dale Henrichs
@dalehenrich
Apr 13 2016 20:54
sounds like a plan ...