Page 2 of 2

Re: OSDK 1.11

Posted: Tue May 15, 2018 7:25 am
by ibisum
So, I respect the very learned professionals' opinions in this thread, even though I (as a learned professional) do not entirely agree that the fault lies in the design of the tools - but rather the motivations (or lack thereof) of the users.

However, in order for this to be productive, I set aside my differences of opinion - and yes, it would be great if I could be considered a safe contributor to the OSDK GitHub repo - there aren't a great deal many changes for me to commit, probably I could've just described the changes in less characters than I've committed to this thread already .. its just more about the workflow of the community that I wish we could improve.

You guys who have done so much already deserve a lot of credit for having gotten us this far without proper version control, that is for sure. ;). Your temerity under such conditions is worthy of respect.

The issue I have is the SVN <--> GIT bridging work that would need to be done in order to keep different forks of the code in sync. In a community where the majority of the most significant contributors despises modern version control techniques, adding another set of version control technologies seems like a bit of a smell. Maybe its not that significant an amount of effort, lets see. I'll be quite happy to just push stuff up to the GitHub Repo and then let the COPY+ZIP brigade sort it out, as long as there is a place I can point other Git-nerds to, if they want to get involved that way too.
I fail to understand why working on Git prevents you from sharing your changes with others.
@NekoNoNiaow: FTR, I'm also a Unix geek, almost a greybeard at this point. Me working with Git doesn't prevent me from sharing code with others - its just that, the Git-hating crew are less likely to see the changes unless someone functions as a bridge between the two worlds. The "staging" issue is something we're definitely crossing lines over, but it doesn't really matter - it means one thing in SVN and has a different meaning in Git. I think that where a lot of confusion lies is the fact that, for Git newbies and detractors alike, the idea of having a locally maintained index of the state of the repo is a bit confusing - the thing to remember is that Git tracks everything unless you tell it not to, and any changes that have occurred since the last time it updated its local index, are simply 'staged locally for commit'. Anyway, here is a nice tutorial that I've given to other Git-haters in the past, and it has worked, at least a few times, to make the pain go away - I mean, I've seen new Git users born from having spent an hour just grok'ing this page, anyway: http://rogerdudler.github.io/git-guide/ If its of any use to our little community, lets see. No worries otherwise - those of us who can handle Git, can handle it - and then the SVN/COPY+ZIP brigade will have something to complain about, or not, depending on whether I'm actually doing something valuable to the codebase .. ;)

And now, for those who have been reading this thread because they want to build OSDK tools on MacOS, here are two very minor changes which have to be made for MacOS:

**Remove fcloseall() call, as we do not have this on MacOS**:

Code: Select all

Index: main/link65/sources/Link65.cpp
===================================================================
--- main/link65/sources/Link65.cpp	(revision 1473)
+++ main/link65/sources/Link65.cpp	(working copy)
@@ -9,7 +9,7 @@

 #include "infos.h"

-#define _GNU_SOURCE 1 /* for fcloseall() */
+//#define _GNU_SOURCE 1 /* for fcloseall() */
 #include <assert.h>
 #include <stdio.h>
 #include <stdlib.h>
@@ -536,7 +536,7 @@
 #ifndef _POSIX_VERSION
   flushall();
 #endif
-  fcloseall();
+//  fcloseall();
 }

**.. and use stdlib.h to gain access to malloc() def's on MacOS:**

Code: Select all

Index: main/pictconv/sources/dither_riemersma.cpp
===================================================================
--- main/pictconv/sources/dither_riemersma.cpp	(revision 1473)
+++ main/pictconv/sources/dither_riemersma.cpp	(working copy)
@@ -8,7 +8,7 @@
 * large memory model. For other compilers, you may have to replace the
 * calls to malloc() and _ffree() with straight malloc() and free() calls.
 */
-#include <malloc.h>     // for malloc() and _ffree()
+#include <stdlib.h>     // for malloc() and _ffree()
 #include <math.h>		// for exp() and log()
 #include <string.h>		// memmove()

If someone with more canonical upstream access on SVN would make these changes and verify it doesn't break Linux/Windows builds, then I'm quite content with ignoring the whole Git issue and just moving on to hacking on my Oric project ..

Re: OSDK 1.11

Posted: Tue May 15, 2018 8:32 am
by Chema
In a community where the majority of the most significant contributors despises modern version control techniques
Well I am not even a minor contributor for the OSDK project (maybe yelling when something does not work for me, little else) but I surely don't despise modern version control. It is simply that I always get confused. I am declaring my ignorance here. But be sure that I am aware of the advantages and I am willing to learn.

BTW, some tools are from Fabrice Frances. I am aware he has some repo here:
https://sourceforge.net/projects/euphorictools/files/
where he keeps them updated, although there are other repos with old unofficial copies (which should NOT be there in my opinion).

My question is... the OSDK currently includes some of these tools, but I am unaware of the versions. For instance, Fabrice modified the tap2cd so it works much more reliably, modified writedsk so it formats the disk by default, instead of skipping formatting if the disk is already formatted (which destroyed interleaving in the dsk image), and so on.

I understand it is impossible to automatically include the last versions somehow, because some command-line parameters may have changed for instance...

Re: OSDK 1.11

Posted: Tue May 15, 2018 9:03 am
by Dbug
The original reason for the OSDK having its own set of Fabrice tools is that originally this repository on SourceForge did not exist, and Fabrice builds were compiled for DOS, failing to run on 64 bit windows.

But yeah, I should import all his changes, should probably do that when I get the time to do the compiler and assembler upgrades.

And indeed there's no version number indicated for http://osdk.org/index.php?page=document ... ge=tap2wav, most tools have, not that one. If you look at the issues, there's been a bunch of things fixed there on your request a couple years back :)

Re: OSDK 1.11

Posted: Tue May 15, 2018 11:10 am
by Chema
Dbug wrote:
Tue May 15, 2018 9:03 am
If you look at the issues, there's been a bunch of things fixed there on your request a couple years back :)
I know :) Thanks!

BTW, once you get some free time (and update certain web page with new versions) we have to talk about a new version of FloppyBuilder. I mean the code to access disks and such things, so my updated routines can be integrated; but first they should be made general.

Maybe a chat in the Oric channel or through messenger.

Re: OSDK 1.11

Posted: Wed May 16, 2018 4:35 am
by NekoNoNiaow
Dbug wrote:
Mon May 14, 2018 6:47 pm
- For the git users, there's already a OSDK github depot, I think it was Godzil maintaining it, you can totally synchronize all of you together
I did look at it a few weeks ago but it has been abandoned since 2011 and is lagging quite behind the current version.
The repository I created has the very latest changes.
Dbug wrote:
Mon May 14, 2018 6:47 pm
- Regarding TestSuite, there are some regression tests for PictConv, and I do run many of the samples to make sure things are not broken, and there's Coverity for the code regression, but yeah, there's no bit "all in one" system, mostly because it's my hobby, and I also like to do funny things, not only core system stuff.

/me goes back to fixing critical stuff for work
I can feel in your "voice" that we should let you in peace until your crunch period is over. ;)
This said, slap Rui on my behalf in the groin for making you guys crunch, tell him I thought he was less evil than that. ;)

Thanks for the feedback on the test suite! It makes sense that you did not invest too much into it of course.
Since it looks like several people are willing to participate, that could be something they can add to since everyone would benefit.
ibisum wrote:
Tue May 15, 2018 7:25 am
[...] and yes, it would be great if I could be considered a safe contributor to the OSDK GitHub repo - there aren't a great deal many changes for me to commit, probably I could've just described the changes in less characters than I've committed to this thread already ..
Great, can you give me your GitHub account name so I can give you permission to push to it?
It would be great if you could use a dedicated branch so we can decide selectively how to bring it back to master (and thus SVN).
ibisum wrote:
Tue May 15, 2018 7:25 am
its just more about the workflow of the community that I wish we could improve.
We are working on it, are we not? ;)
ibisum wrote:
Tue May 15, 2018 7:25 am
The issue I have is the SVN <--> GIT bridging work that would need to be done in order to keep different forks of the code in sync.
[...]
I'll be quite happy to just push stuff up to the GitHub Repo and then let the COPY+ZIP brigade sort it out, as long as there is a place I can point other Git-nerds to, if they want to get involved that way too.
I think this is an issue we can address when our production is so large as to overwhelm that bridge. ;)
It would be nice if we were there yet but I have a feeling that is not the case. (ˆˆ)

Every long journey starts with a small step. No abrupt change ever brings anything good. ;)
ibisum wrote:
Tue May 15, 2018 7:25 am
@NekoNoNiaow: FTR, I'm also a Unix geek, almost a greybeard at this point. Me working with Git doesn't prevent me from sharing code with others - its just that, the Git-hating crew are less likely to see the changes unless someone functions as a bridge between the two worlds.
Bridge which I have explicitly offered to maintain so all is good. ;)
Moreover, as said above we are far from a situation where we produce so much code that we cannot handle it. I am confident that Git's advantages over SVN when working together is concerned will eventually win everyone over. Especially with the great UI and services offered by GitHub that could be made use of if DBug judges them useful (automated builds, releases storage, test suite, etc.).
ibisum wrote:
Tue May 15, 2018 7:25 am
And now, for those who have been reading this thread because they want to build OSDK tools on MacOS, here are two very minor changes which have to be made for MacOS:
[...]
If someone with more canonical upstream access on SVN would make these changes and verify it doesn't break Linux/Windows builds, then I'm quite content with ignoring the whole Git issue and just moving on to hacking on my Oric project ..
PM sent to you so you can give me your GitHub account name and we discuss branching on GitHub without polluting this thread which I already brought quite off topic. ;)
I need to get used to bring back GitHub changes to SVN so that will be a good starting exercise.

Re: OSDK 1.11

Posted: Wed May 16, 2018 7:47 am
by ibisum
Great! I respect the inspiration here!
I need to get used to bring back GitHub changes to SVN so that will be a good starting exercise.
I think this is something you can probably script up to run automatically after pushing to master, no?

Anyway, PM's exchanged, lets get our Github fort built and ready for business ..

Re: OSDK 1.11

Posted: Thu May 17, 2018 10:30 am
by Dbug
Let's be clear on one point: Me migrating to GIT would not imply to me migrating to GITHUB or any other online GIT hosting system.

As I've said numerous time: Defence-Force.org has been running for longer than half of the websites around here, it was here before GoogleCode, it was here before CodePlex, and has outlived both: I do not invest time in things that are not guaranteed to outlive my own personal website.

Also I do not put my eggs in services that are actively policing content and enforcing censorship: If I want to write FUCK in my source code, or "this routine is a piece of shit", I deny the right to the all encompassed moral guardians of these websites to shut down my repository or remove the offending words.

What that means is that if at some point the SVN depot gets converted to GIT, it would also be hosted on my servers, and it may even only concern the OSDK, with the existing projects and user folders on SVN staying available as is.

I can understand why contributors to a multi-persons projects wants something more fancy with branches and complicated workflow, but I don't want to impose either an overly complicated and user-hostile system to people who just want a simple revision system for their own games and small projects.

Re: OSDK 1.11

Posted: Thu May 17, 2018 2:02 pm
by ibisum
Yeah, a private instance of GitLab is pretty easily fired up .. I've no horse in the race, either way, I just prefer Git and have seen its power used very effectively over the decades .. either way though, we've got a Git repo now, and those of us who want to use it can .. if you eventually set up GitLab (or whatever), as of now it'll be very easy to migrate community-contributed code to it ..

Re: OSDK 1.11

Posted: Thu May 17, 2018 2:12 pm
by Chema
Dbug wrote:
Thu May 17, 2018 10:30 am
Let's be clear on one point: Me migrating to GIT would not imply to me migrating to GITHUB or any other online GIT hosting system.

As I've said numerous time: Defence-Force.org has been running for longer than half of the websites around here, it was here before GoogleCode, it was here before CodePlex, and has outlived both: I do not invest time in things that are not guaranteed to outlive my own personal website.
hehe excellent point.

+1