[subexp-daq] nurdlib now under lgpl-2.1 and public

[Hans Toshihide Törnqvist]

Dear Philipp et al.,

That was enough suggestions for me regarding the online repos, I will 
consider the following two in the future:

https://github.com/nustardaq/nurdlib
https://gitlab.com/chalmers-subexp/nurdlib

The others are available for now and should be synced, but if they break 
they will probably be removed.

I created the 'nustardaq' Github team for this and am currently the 
leader I suppose. Definitely not intentional, I will happily relinquish 
that role :)

The docu needs a kick I agree. I will keep the current options, but will 
move towards the Sphinx page being a cheat sheet and the pdf the dry 
reference. The pdf should be easier to get, yes.

I see quite a few names in the upexps git history, so that should not be 
the obstacle.

Best regards,
Hans


On 2024-05-17 00:44, Philipp Klenze wrote:
> Dear Hans,
> that is great!
> 
> I would prefer using either github or gitlab.com for discussion as users 
> are more likely to already have credentials for these platforms.
> 
> Also, in the docs there is one .tex file (by you) and one sphinx-file 
> (which uses a python configuration, so possibly not by you)? It might be 
> better to remove one of them -- I can handle pdf, I can handle rst or 
> html, but not knowing which docs to read might not be ideal. (Also, 
> putting the pdf on the web instead of telling people to just git clone 
> and run make to compile the latex might be nice).
> 
> Other than r3bfuser (which you mentioned) and the silly R3BRoot 
> parameter repositories, the only thing which remains closed source is 
> upexps. I think the two reasons blocking upexps are that (a) it is not 
> entirely clear who contributed and (b) in the present state it would be 
> a bit like open sourcing the Necronomicon. :)
> 
> Cheers,
> Philipp
> 
> PS: I think I have managed to figure out the rest of how wrtclk 
> exploders operate. I have crafted nice labels for the lemo ports as well 
> as a few caveats (for example, Bastii's serial/jumper adapter board also 
> fits in with an offset of +/-2.54mm). The plan is to document all of 
> this tomorrow.
> 
> PPS: The wrtclk can either run with a clock of an upstream system 
> (rataclock 25MHz, Butis) or with an internal clock. One thing which I 
> found is that when the inputs get disconnected, the timestamps still 
> increase at approximately the correct rate when the internal clock is 
> used. I think the main advantage of running with the upstream clock is 
> that it is impossible to oversee this condition, while for the 
> free-running clock it would depend on the precision of the exploder 
> oscillator how long it takes to see the drift in treeview. Or do 
> ratatime/rataclock transmit a "bad timestamp"-bit in these cases?
> 
> On 16/05/2024 23.20, Hans Toshihide Törnqvist wrote:
>> Dear all,
>>
>>
>> I have finally parsed all nurdlib files and slapped the LGPL-2.1 on 
>> the ones that need it, reset the git history, and put the whole thing 
>> in several public places:
>>
>> https://github.com/hanstt/nurdlib
>> https://git.gsi.de/r3b/nurdlib
>> https://gitlab.com/chalmers-subexp/nurdlib
>> https://git.chalmers.se/expsubphys/nurdlib
>>
>> I have extracted all authors for every file and the years of 
>> modifications according to the git history, then I reset the history 
>> to not have to worry about old mishaps (current and future ones I will 
>> have to answer for...). The old repositories were renamed to 
>> nurdlib.pregpl21 but are otherwise available in the previous 
>> locations, just not publicly.
>>
>>
>> For the curious, I personally push to git.chalmers.se, which has lots 
>> of CI images that are quite painful to reproduce elsewhere. That repo 
>> then mirrors automatically to the other three.
>>
>>
>> The large number of options is mainly a test to see what works. 
>> Eventually I would like to settle on "the one" or "the two" repos 
>> where pull requests, issues, and possibly even a wiki, will be 
>> maintained. I am open to suggestions and arguments!
>>
>>
>> I know of some recent changes (and not so recent ones...) by others 
>> while I was doing this, those should be implemented soon, but please 
>> remind me if I seem to have forgotten. I wanted to get this live and 
>> done with after having postponed this for too long.
>>
>>
>> r3bfuser... Suppose that needs to happen too.
>>
>>
>> Best regards,
>> Hans