from:"corecode"

Re: [PATCH]: today highlighting in [n]cal

2009-04-20 Thread Simon 'corecode' Schubert


Hey Roman,

Roman Divacky wrote:

I made this patch that highlights today in cal/ncal just like gnu
cal does..

www.vlakno.cz/~rdivacky/cal.patch


Thanks for this patch, I've been meaning to hack one up properly, but 
never got to it.  They problems I was facing seem to exist also with your 
patch:


- only works for wide (cal) mode, not ncal mode
- probably won't work properly with year displays:  the year printing 
parts of the code use a length argument to printf (%*s), which will 
confuse escape sequences with actual printed characters


cheers
  simon

--
  3 the future  +++  RENT this banner advert  +++   ASCII Ribbon   /\
  rock the past  +++  space for low €€€ NOW!1  +++ Campaign \ /
Party Enjoy Relax   |   http://dragonflybsd.org  Against  HTML   \
Dude 2c 2 the max   !   http://golden-apple.biz   Mail + News   / \

___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org

Re: [PATCH]: today highlighting in [n]cal

2009-04-20 Thread Simon 'corecode' Schubert


Roman Divacky wrote:

On Mon, Apr 20, 2009 at 11:21:26AM +0200, Simon 'corecode' Schubert wrote:

Hey Roman,

Roman Divacky wrote:

I made this patch that highlights today in cal/ncal just like gnu
cal does..

www.vlakno.cz/~rdivacky/cal.patch
Thanks for this patch, I've been meaning to hack one up properly, but 
never got to it.  They problems I was facing seem to exist also with your 
patch:


- only works for wide (cal) mode, not ncal mode


it works for ncal 


I didn't try it on FreeBSD, but from inspecting the code, you only 
modified mkmonthb(), which is called for the cal-style layout, but not for 
the ncal-style layout (then mkmonth() is called).


- probably won't work properly with year displays:  the year printing 
parts of the code use a length argument to printf (%*s), which will 
confuse escape sequences with actual printed characters


I am not sure what you mean by year printing can you give me the
exact command line?


just try cal 2009 or so, basically use printyear[b].

cheers
  simon

--
  3 the future  +++  RENT this banner advert  +++   ASCII Ribbon   /\
  rock the past  +++  space for low €€€ NOW!1  +++ Campaign \ /
Party Enjoy Relax   |   http://dragonflybsd.org  Against  HTML   \
Dude 2c 2 the max   !   http://golden-apple.biz   Mail + News   / \

___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org

Re: Jail with a back door interface?

2007-11-27 Thread Simon 'corecode' Schubert


Xin LI wrote:

Steven Hartland wrote:

Is it possible to create a jail with more than one IP?
Looking around this doesn't seem possible but is it?


FreeBSD does not support multiple IP nor IPv6 on jails at this moment,
unfortunately...


AFAIK there exists a patch by pjd@

If not, somebody could also try porting the DragonFly multi ip + ipv6 changes 
to jail.  They're not so complex and should be rather simple to bring over.

cheers
 simon

--
Serve - BSD +++  RENT this banner advert  +++ASCII Ribbon   /\
Work - Mac  +++  space for low €€€ NOW!1  +++  Campaign \ /
Party Enjoy Relax   |   http://dragonflybsd.org  Against  HTML   \
Dude 2c 2 the max   !   http://golden-apple.biz   Mail + News   / \
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]

Re: questions on development(7)

2007-11-14 Thread Simon 'corecode' Schubert

[cc cleaned, dropped -current]

Giorgos Keramidas wrote:
 I'm only tracking 'HEAD' most of the time, but there are some efforts
 underway to convert the history of src/.  One notable example is the
 effort to convert to Subversion first, and then use the tags/branches
 and changesets of Subversion to populate an Hg tree.

That seems wrong.  A conversion to subversion means losing precision and
time.

 Also cvs20hg doesn't appear to grok Hg branches (probably because it
 predates them) and it would be Really Nice(tm) if it did.

cvs20hg is deprecated since two years or so.  Please try fromcvs
instead.  There are some bugs left, of course.  Last thing it seems I
introduced some memory overflow problem, so that a conversion of src now
runs out of memory (on a 32bit machine).  Up to a couple of months ago
this was running very smoothly, see [1].

However I don't think that using named branches in hg is a nice or
elegant thing anyways.  But that's OT, of course.

 Both true.  But we are off in a tangent.  If you have interesting bits
 about Hg or other dSCMs, please contact me off-list or help us keep the
 wiki pages about Version Control up to date.

I suppose you know about fromcvs.  I also guess you know that I suggest
using git instead of hg.  Doesn't produce nasty large index files either :)

cheers
  simon

___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]

Re: questions on development(7)

2007-11-14 Thread Simon 'corecode' Schubert

OutbackDingo wrote:
 I suppose you know about fromcvs.  I also guess you know that I suggest
 using git instead of hg.  Doesn't produce nasty large index files either :)
 So would you think cvs - git - hg might be easier to accomplish ??
 Since one of my goals is to update projects Ive done based on FreeBSD
 that require OS level updating

No, I think git is the better SCM, but that's a personal decision.

Fromcvs converts to both hg and git, using the same algorithm.  I'd
appreciate any help fleshing out the last bugs (also re: scalability).
I'm considering it beta grade quality, but I know of many people using
it on a daily basis without problems.

cheers
  simon

___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]

Re: questions on development(7)

2007-11-14 Thread Simon 'corecode' Schubert

Giorgos Keramidas wrote:
I'm only tracking 'HEAD' most of the time, but there are some efforts
underway to convert the history of src/. One notable example is the
effort to convert to Subversion first, and then use the tags/branches
and changesets of Subversion to populate an Hg tree.
That seems wrong. A conversion to subversion means losing precision
and time.
Can you elaborate a bit. I am not sure I got why you lose precision.

This is due to the fact that CVS doesn't have changesets. It is too
late now and it is also quite complicated to explain, but it boils down
to the fact that aggregating changesets will remove information, namely
the single file revisions, which you could use for a direct conversion
to hg/git.

Also cvs20hg doesn't appear to grok Hg branches (probably because it
predates them) and it would be Really Nice(tm) if it did.
cvs20hg is deprecated since two years or so.
I know that. It's just that fromcvs doesn't quite work for me here,
yet, so I had to stick with a patched cvs20hg version.

I am surprised that cvs20hg works better. Fromcvs allows you to ignore
certain branches, maybe that's what you need?

Please try fromcvs instead. There are some bugs left, of course.
Last thing it seems I introduced some memory overflow problem, so that
a conversion of src now runs out of memory (on a 32bit machine). Up
to a couple of months ago this was running very smoothly, see [1].

Something is missing for [1], I guess :)

yes, sorry.

[1] http://www.theshell.com/cgi-bin/gitweb.cgi/

I tried fromcvs to the doc/ tree (non-branched, less repo-surgery
magic to handle), but it stops with a traceback very soon:

% $ pwd
% /home/keramida/hg/fromcvs/fromcvs
% $ ruby tohg.rb /home/ncvs doc ~/tmp/foo
% [...]
% /home/ncvs/doc/bn_BD.ISO10646-1/articles/new-users
% /home/ncvs/doc/bn_BD.ISO10646-1/articles/explaining-bsd
% /home/ncvs/doc/FAQ/Attic
% upgrading roberto to 1/ (1.1.1)
% Traceback (most recent call last):
% File ./tohg.py, line 102, in module
% destrepo.dispatch()
% File ./tohg.py, line 98, in dispatch
% func(*l[1:])
% File ./tohg.py, line 78, in cmd_commit
% extra = {'branch': branch})
% TypeError: commit() got an unexpected keyword argument 'wlock'
% tohg.rb:200:in `readline': end of file reached while handling set
[doc/handbook/Attic/troubleshooting.sgml,v:1.1.1.1,doc/handbook/Attic/sup.sgml,v:1.1.1.1,doc/handbook/Attic/slips.sgml,v:1.1.1.1,doc/handbook/Attic/slipc.sgml,v:1.1.1.1,doc/handbook/Attic/scsi.sgml,v:1.1.1.1,doc/handbook/Attic/ppp.sgml,v:1.1.1.1,doc/handbook/Attic/ports.sgml,v:1.1.1.1,doc/handbook/Attic/porting.sgml,v:1.1.1.1,doc/handbook/Attic/nfs.sgml,v:1.1.1.1,doc/handbook/Attic/submitters.sgml,v:1.1.1.1,doc/handbook/Attic/kerberos.sgml,v:1.1.1.1,doc/handbook/Attic/handbook.sgml,v:1.1.1.1,doc/handbook/Attic/glossary.sgml,v:1.1.1.1,doc/handbook/Attic/diskless.sgml,v:1.1.1.1,doc/handbook/Attic/dialup.sgml,v:1.1.1.1,doc/handbook/Attic/eresources.sgml,v:1.1.1.1,doc/handbook/Attic/current.sgml,v:1.1.1.1,doc/handbook/Attic/ctm.sgml,v:1.1.1.1,doc/handbook/Attic/basics.sgml,v:1.1.1.1,doc/handbook/Attic/authors.sgml,v:1.1.1.1,doc/handbook/Attic/bibliography.sgml,v:1.1.1.1]
(EOFError)
% from tohg.rb:200:in `_commit'
% from tohg.rb:122:in `create_branch'
% from ./fromcvs.rb:989:in `commit_sets'
% from tohg.rb:228
% $

I don't know how to read Ruby code, so I can't fix this myself, but any
ideas/help/patches you have I can test easily :)

This is because mercurial changes its API on every release. Somebody
who is using hg and fromcvs needs to update the code. I got tired of this.

I suppose you know about fromcvs. I also guess you know that I
suggest using git instead of hg. Doesn't produce nasty large index
files either :)
I wasn't aware that you strongly prefer Git. Any references I can read,
so find out more about why you do?

Sorry, I didn't write up the reasons. It's more of a personal feeling
and a preference for the git repository layout. This layout allows many
things to be implemented in a very simple way (ref. branches). Also, it
is better suited to have multiple branches in a repo, which is usually
what you want to do if you're syncing with multiple persons. Hg only
has heads.

cheers
simon
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]

61 matches

Mail list logo