Does anyone remember what the problem with producing working PDBs from the Windows build was? I have a colleague with a Windows 7 crash that happens... sometimes. I'd like to send him a debug build so I don't have to decode an assembler trace.
Has anyone tried since we switched to dll-modules?
Haven't gotten around to install and test it yet, but here's a try: https://pike.ida.liu.se/download/pub/pike/alpha/7.8.340/
Will hit it with a debugger tomorrow.
There are PDBs with some sort of content at least. It was not obvious how MSVS is supposed to eat them when debugging, and I was to lazy to read docs just then. Potentially working at least.
I'm not aware of any regressions _against earlier 7.8 builds_ right now, so I think I'll build a beta tonight if no one protests.
Or not. The SQL to JSON stuff broke Windows. Please fix.
The current Pikefarm builds from my machine is not usefull to debug this due to clock scew. So:
#### Making dynamic: modules/Mysql Compiling modules/Mysql/mysql.c Compiling modules/Mysql/result.c B:\test\Pike-v7.8.342\src\modules\Mysql\result.c(688) : error C2143: syntax error : missing ';' before 'type' B:\test\Pike-v7.8.342\src\modules\Mysql\result.c(689) : error C2065: 'res' : undeclared identifier B:\test\Pike-v7.8.342\src\modules\Mysql\result.c(689) : warning C4133: 'function' : incompatible types - from 'int *' to 'string_builder *' B:\test\Pike-v7.8.342\src\modules\Mysql\result.c(690) : error C2065: 'res' : undeclared identifier B:\test\Pike-v7.8.342\src\modules\Mysql\result.c(690) : warning C4133: 'function' : incompatible types - from 'int *' to 'string_builder *' B:\test\Pike-v7.8.342\src\modules\Mysql\result.c(697) : error C2143: syntax error : missing ';' before 'type' B:\test\Pike-v7.8.342\src\modules\Mysql\result.c(707) : error C2065: 'r' : undeclared identifier B:\test\Pike-v7.8.342\src\modules\Mysql\result.c(708) : error C2065: 'res' : undeclared identifier B:\test\Pike-v7.8.342\src\modules\Mysql\result.c(708) : warning C4133: 'function' : incompatible types - from 'int *' to 'string_builder *' B:\test\Pike-v7.8.342\src\modules\Mysql\result.c(710) : error C2065: 'res' : undeclared identifier
*snip*
Which goes to show that the 7.9 development should be happening in git ASAP. Is there anything left on the todo-list for that switchover? Is there a list?
Martin Nilsson (Opera Mini - AFK!) @ Pike (-) developers forum wrote:
Which goes to show that the 7.9 development should be happening in git ASAP. Is there anything left on the todo-list for that switchover? Is there a list?
There still is a final history-rewrite pending. But that shouldn't stop any new development. It would mean at some point in time we would need to rebase once (to get back in sync with the new & improved history).
However, the git repository running the mirror is running very stable and hasn't hickupped for the past 11 months. IMO it is ready for production, opening an official 7.9 branch there takes about a second. I'd guess that adapting pikefarm to read from the git repository is still on the todo list.
Martin Nilsson (Opera Mini - AFK!) @ Pike (-) developers forum wrote:
Which goes to show that the 7.9 development should be happening in git ASAP. Is there anything left on the todo-list for that switchover? Is there a list?
There still is a final history-rewrite pending. But that shouldn't stop any new development. It would mean at some point in time we would need to rebase once (to get back in sync with the new & improved history).
I believe we'll want to do a reexport with a cvsps containing mast's patches first as well.
However, the git repository running the mirror is running very stable and hasn't hickupped for the past 11 months. IMO it is ready for production, opening an official 7.9 branch there takes about a second. I'd guess that adapting pikefarm to read from the git repository is still on the todo list.
Adapting pikefarm should be simple to do.
I agree that it's time to branch off 7.9.
-- Sincerely, Stephen R. van den Berg.
I believe we'll want to do a reexport with a cvsps containing mast's patches first as well.
Ah, yes. Because of the coming migration to git at Roxen, I've been hacking a bit the last months on cvsps and git-cvsimport to make them work decently (I started on it before I noted the bit at the end of git-cvsimport(1) enumerating all its serious faults). I got most things sorted out now, including vendor branch mirroring etc.
I've pushed my patches to srb's repo at pike-git.lysator.liu.se:cvsps.git/.git
If cvsps/git-cvsimport is used for the pike repo then I strongly suggest using my patched tools, but I got the impression that other tools are used since it's based on Comstedts svn export, right?
Btw, in my conversion of (mainly) the Roxen Webserver repo, I've done some other things which I think are nice. One is to include the cvs revisions in old commit messages, since cvs commits might refer to other commits that way. E.g:
commit dbe28d2 Author: Henrik Grubbström grubba@grubba.org Date: Fri May 15 14:30:26 2009 +0200
First go at automatic database backups. Currently disabled by ENABLE_DB_BACKUPS.
[subtabs.pike 1.18, DBManager.pmod 1.86]
server/config_interface/dbs/subtabs.pike | 21 + server/etc/modules/DBManager.pmod | 595 ++++++++++++++++++++++++++++-- 2 files changed, 577 insertions(+), 39 deletions(-)
Another is to make tag names look nicer by converting "_" to "-" or ".", e.g. "roxen_5_0_366" in cvs becomes "roxen-5.0.366" in git.
I can of course provide my scripts and stuff for that if someone wants it.
Martin Stjernholm, Roxen IS @ Pike developers forum wrote:
I believe we'll want to do a reexport with a cvsps containing mast's patches first as well.
I've pushed my patches to srb's repo at pike-git.lysator.liu.se:cvsps.git/.git
Ah, nice.
If cvsps/git-cvsimport is used for the pike repo then I strongly suggest using my patched tools, but I got the impression that other tools are used since it's based on Comstedts svn export, right?
It is, but I've been meaning to run a script checking out every CVS revision in the past, and comparing it with what I have.
Btw, in my conversion of (mainly) the Roxen Webserver repo, I've done some other things which I think are nice. One is to include the cvs revisions in old commit messages, since cvs commits might refer to other commits that way. E.g:
[subtabs.pike 1.18, DBManager.pmod 1.86]
If that is being used for reference in the CVS repository commits, I'm all for it.
If cvsps/git-cvsimport is used for the pike repo then I strongly suggest using my patched tools, but I got the impression that other tools are used since it's based on Comstedts svn export, right?
It is, but I've been meaning to run a script checking out every CVS revision in the past, and comparing it with what I have.
A good plan. By the way, the svn repository is currently a bit out of date due to the CVS rsync on eureka not working, but I think it should be fine to use what exists now, and pull all changesets after that directly from CVS. If not, just let me know and I'll resync the svn repo (assuming the rsync functionality has been reestablished).
It is, but I've been meaning to run a script checking out every CVS revision in the past, and comparing it with what I have.
A good idea, but beware that that doesn't necessarily give the correct view of what a real cvs checkout gave at that time, since the ,v files have been moved around etc. I've spent some time reconstructing such moves/copies/deletes for the WebServer repo. E.g. here's a snippet from the 2.0 branch:
# This tablist.pike forked off server/modules/tags/configtablist.pike # sometime between 1999-08-05 03:00:22 +0200 and 1999-09-28 17:46:51 +0200. cvs_repo_rm server/modules/tags/Attic/tablist.pike stop_date_1="1999-08-05 03:00:23 +0200"
# Judging from log divergence, these files were copied from the 1.3 # tree between 2000-02-04 15:29:44 +0100 and 2000-02-10 06:40:34 +0100. # Judging from the tagging, they were copied between # 1999-08-25 03:01:45 +0200 and 2000-02-06 16:40:45 +0100. #cvs_repo_rm server/modules/ldap/ldaptag.pike #cvs_repo_rm server/modules/ldap/ldapuserauth.pike
# Moved here from server/modules/tags at 2000-04-05 16:31:58 +0200. cvs_repo_rm server/modules/database/sqltag.pike # Moved here from server/modules/misc at 2000-04-05 16:32:38 +0200. cvs_repo_rm server/modules/database/SQLuserdb.pike cvs_repo_rm server/modules/database/sqldb.pike stop_date_2="2000-04-05 16:32:39 +0200"
# 1.2 had a different version of tablist.pike in the graphics dir. # The old one is still in the attic, so just remove this to make it # show. The attic version got removed at 1999-09-29 12:26:28 +0200. # This one was moved here from server/modules/tags at # 2000-04-06 08:16:07 +0200. cvs_repo_rm server/modules/graphics/tablist.pike stop_date_3="2000-04-06 08:16:08 +0200"
In my conversions I've only checked that the branch heads are identical to the cvs repo's.
Martin Stjernholm, Roxen IS @ Pike developers forum wrote:
It is, but I've been meaning to run a script checking out every CVS revision in the past, and comparing it with what I have.
A good idea, but beware that that doesn't necessarily give the correct view of what a real cvs checkout gave at that time, since the ,v files have been moved around etc. I've spent some time reconstructing such
I realise that. The logic verifying the checkouts needs to selectively ignore things like that. The most likely errors I want to catch are simple import errors which result(ed) in corrupted commits (e.g. all the missing CRs in the SVN repository which broke all binary files (like gifs)).
A good idea, but beware that that doesn't necessarily give the correct view of what a real cvs checkout gave at that time, since the ,v files have been moved around etc.
The early days were certainly a wild west in this regard (also, there were module imports from other repos as well, which further complicates comaparison). For 7.1 and up, I _think_ it should be more or less ok as long as you dont try to e.g. check out a 7.2 from the 7.4 repository etc.
I have a list of all the irregularities which the svn converter compensates for, but I guess it will be a better check if you don't depend on that one being correct...
Tonight that is, because I don't have enough credentials to do it from where I am apparently.
Peter Bortas @ Pike developers forum wrote:
Tonight that is, because I don't have enough credentials to do it from where I am apparently.
No worries. I used the complete history-snapshot from SVN at around nov 2007 to jumpstart the git import, after that I just use direct CVS imports to keep in sync with the latest updates. I'm not sure who is following the SVN repository, but the git mirror isn't (at least).
Ok, then the current repo (which is complete up to January 2009) should be sufficient for a rebase.
Marcus Comstedt (ACROSS) (Hail Ilpalazzo!) @ Pike (-) developers forum wrote:
Ok, then the current repo (which is complete up to January 2009) should be sufficient for a rebase.
Do you, by any chance, have scripts which checkout a revision from the SVN repository and also checkout the corresponding revision from a CVS repository?
Do you, by any chance, have scripts which checkout a revision from the SVN repository and also checkout the corresponding revision from a CVS repository?
Nope, sorry. The date of the commit should be usable, although I'm unsure if a grouped set of commits use the date of the first CVS commit or the last one (that's part of cvs2svn:s functionality).
Thanks. However, I ran into this error, which I haven't seen before:
Error summary: ERROR: A CVS repository cannot contain both /cvsroot/Pike/nt-tools/tools/sdl-config,v and /cvsroot/Pike/nt-tools/tools/Attic/sdl-config,v ERROR: A CVS repository cannot contain both /cvsroot/Pike/nt-tools/tools/sdl-config.disabled,v and /cvsroot/Pike/nt-tools/tools/Attic/sdl-config.disabled,v Exited due to fatal error(s).
Did someone actually go fiddling with these ,v files, or is this a problem with the rsync?
pike-devel@lists.lysator.liu.se
-
Henrik Grubbstr�m (Lysator) ＠ Pike (-) developers forum -
Marcus Comstedt (ACROSS) (Hail Ilpalazzo!) ＠ Pike (-) developers forum
-
Martin Nilsson (Opera Mini - AFK!) ＠ Pike (-) developers forum
-
Martin Stjernholm, Roxen IS ＠ Pike developers forum
-
Peter Bortas ＠ Pike developers forum
-
Stephen R. van den Berg