OSDev.org

The Place to Start for Operating System Developers
It is currently Wed Jun 20, 2018 12:13 am

All times are UTC - 6 hours




Post new topic Reply to topic  [ 19 posts ]  Go to page Previous  1, 2
Author Message
 Post subject: Re: Where did PDCLIB go? (or: what are the alternatives?)
PostPosted: Thu Mar 03, 2016 3:27 am 
Offline
Member
Member
User avatar

Joined: Thu Nov 16, 2006 12:01 pm
Posts: 7229
Location: Germany
Aside from some cleanup on web links, Owen has kindly provided me with write access to the PDCLib repository.

I'm in the process of re-familiarizing myself with the project structure, the changes and improvements done by Owen, and the different environment. (I've never worked with either Jam or Mercurial so far.)

My first couple of changes will probably be related to various compiler warnings I am getting (something I was always a bit OCD about), and applying the patch suggested by darkinsanity. (I don't have clang set up ATM, but it seems to make sense and I'll take his word for it.) A good way to get back "the feel", without being disruptive.

_________________
Every good solution is obvious once you've found it.


Top
 Profile  
 
 Post subject: Re: Where did PDCLIB go? (or: what are the alternatives?)
PostPosted: Thu Mar 03, 2016 4:43 am 
Offline
Member
Member
User avatar

Joined: Wed Oct 18, 2006 3:45 am
Posts: 9228
Location: An der schönen blauen Donau, watching muppets
I see I have a lot of my ancient pdclib stubs to replace with proper versions :D

_________________
"Certainly avoid yourself. He is a newbie and might not realize it. You'll hate his code deeply a few years down the road." - Sortie
[ My OS ] [ VDisk/SFS ]


Top
 Profile  
 
 Post subject: Re: Where did PDCLIB go? (or: what are the alternatives?)
PostPosted: Mon Apr 04, 2016 12:29 am 
Offline
Member
Member
User avatar

Joined: Thu Nov 16, 2006 12:01 pm
Posts: 7229
Location: Germany
A quick update.

Owen did significant improvements to the (rather broken) <stdio.h> implementation I delivered in v0.5. This, however, was entwined with adding <threads.h>, multibyte and wide character support, and a couple of supported platforms (splitting the test-only "example" platform into "example", "posix", "win32", and "gandr") -- which I, personally, would not have tackled before <stdio.h> was truly patched and fixed.

I found it difficult to re-orient myself amidst the numerous (helpful) changes Owen did to the codebase, and pretty quickly met the point where I was afraid that further changes would bring more harm than good.

I created a branch at the point where Owen took over in 2012, to "retrace" his steps. There were several ideas behind this:

  • Being able to work from a "familiar" codebase;
  • working toward an understanding of Owen's changes and additions step-by-step instead of all-at-once;
  • not getting tangled between "content" changes and "style" changes;
  • verifying that implementations are "correct" and "complete", again step-by-step.

The idea was to reach a point where I could merge "my" branch and "Owen's" branch to, basically, form a release-worthy v0.6 I felt I could competently support and maintain toward later releases.

Seeing how <threads.h> figured prominently in Owen's changesets (and, really, should be considered from the start for the various thread-static things necessary for locale / multibyte / time support), and seeing how <threads.h> included <time.h>, I figured I'd start with creating a <time.h> implementation (which is missing from Owen's branch).

This was a part of the standard I haven't looked at or used before, and a fine bag of laughs it is. Not because of any shortcomings in the standard, but because a) times and dates are a rather non-trivial subject, and b) Linux did a rather poor job abstracting the kernel interface at some point. For <stdio.h>, there are things like open() / close() / read() that work just fine as lib-to-OS plumbing, but in the time area, the borders are entangled indeed.

I think I got it, though.

So, at this point I have time(), clock() and timespec_get(), i.e. the functions to get time information from the kernel, and strftime(), i.e. the function to print time information in custom format.

The next thing is the implementation of time zone and DST support... which is entangled with locales, and stdio... which in my branch is not reliable yet.

Oh joy. :-D

I've just downloaded the tzcode / tzdata packages from http://www.iana.org/time-zones, and will keep hacking this into submission. Stay tuned. ;-)

----

Post Scriptum: Of course the "default" branch remains the one to download / use at any point. After all, it is the one with the working <stdio.h>... I will merge any significant improvements of the "retrace" branch back to "default" at regular intervals.

_________________
Every good solution is obvious once you've found it.


Top
 Profile  
 
 Post subject: Re: Where did PDCLIB go? (or: what are the alternatives?)
PostPosted: Mon Jun 11, 2018 4:20 am 
Offline
Member
Member
User avatar

Joined: Thu Nov 16, 2006 12:01 pm
Posts: 7229
Location: Germany
After Rink Springer buggered me about the lack of work done on PDCLib, I took the project under my own wing again.

https://rootdirectory.ddns.net/dokuwiki/doku.php?id=pdclib:start

There is branches/shepherd, and trunk (my own work, formerly "retrace" branch).

_________________
Every good solution is obvious once you've found it.


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 19 posts ]  Go to page Previous  1, 2

All times are UTC - 6 hours


Who is online

Users browsing this forum: No registered users and 2 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group