Re: [ctwm] Crash fix for when WorkSpaces not defined
On Fri, Nov 23, 2007 at 04:26:01AM +0100 I heard the voice of Richard Levitte, and lo! it spake thus: In message [EMAIL PROTECTED] on Fri, 23 Nov 2007 02:00:33 +0100, Rhialto [EMAIL PROTECTED] said: I pulled a new monotone repository and looked at it with monotone-viz, and something weird is going on. Maybe it's a monotone bug, or it may be with monotone-viz. Actually, it's less weird than you might think. I assume that Matthew did some hacking in a branch of his own, but since that branch is most probably not among those he's allowed to write to, the revisions themselves come over, but the branch certs do not. So basically, the edge between e07ab7de496e218dc324fe3a9cb66d85dde116d8 and a97d0dcc8eaf6e94ce9190d98913789d9dbbd37f represent the move from the ctwm branch to Matthew's private hackng branch, and the edge between 6eb1af5f822cafe715c4e46f37ea3bc808e7a5f5 and 4da54949171b2cc1c5f467318daf87b683a77d9b represent the move back into the ctwm branch. Yes, the entire run from a97d0dcc up through 4da549 happened in my private branch. While mtn isn't the way I went for my own stuff, working with a DVCS has well trained me to make throwaway branches for anything that looks likely to take more than 1 commit to do. I'm not sure what viz is showing breakage for, though; eyeballing the ancestry, it's unbroken, and I thought propagate would add on the X.ctwm branch certs. This is the boundaries of my mtn understanding, though. My workflow goes something like: - I have an 'upstream' repo which is what I pulled from guardian, and what I push back via. - I have a 'fullermd' repo into which I pulled just the X.ctwm branch from my 'upstream' repo, and in which I do my work. Then I propagate from my working branch into that X.ctwm, do a 'push' from there (which pushes that X.ctwm back to the 'upstream' repo), then go over to upstream and push it to guardian. The reasoning behind this is that such branches are throwaway; once they've done their job, they should just be tossed in the bitbucket since they don't have any further reason to exist. But once the branch sneaks out of my repo into upstream, it's eternal; I may get into the plumbing and delete it, but it'll reappear next time somebody else re-syncs. This way, the branches don't leak upstream, and when too many of them start showing up I can just rm the repo and re-create it (well, except that it also has the branch that I use for the local changes in my running ctwm... I guess I'll have to make a third repo for that when I get around to dumping this). So I have to go through extra hoops to keep my branches from leaking upstream. mtn docs don't tell me near enough to figure out appropriate ways of setting patterns (they barely tell me that there ARE patterns and how to see them) for syncing; I'm not even sure you CAN specify multiple levels of allow/deny. And anyway, it'd just accumulate unnecessary and distracting clutter over time. Thus, a bunch of contortionism. -- Matthew Fuller (MF4839) | [EMAIL PROTECTED] Systems/Network Administrator | http://www.over-yonder.net/~fullermd/ On the Internet, nobody can hear you scream.
Re: [ctwm] Crash fix for when WorkSpaces not defined)
On Fri, Nov 23, 2007 at 11:35:52AM +0100 I heard the voice of Richard Levitte, and lo! it spake thus: It's not a problem, it's the way mtn-viz is designed. It only displays revisions from the selected branches, plus entering and exiting revisions of propagates. Matthew's private revisions do not have branch certs (except in his database), and therefore belong to no branch, and are therefore unselectable (and undisplayable) by mtn-viz. Well, OK (and in my database, they're not on X.ctwm, they're on free.lp.se:X.ctwm.compiler_errors, so even a viz on X.ctwm there wouldn't show them?). But if prop doesn't do so (why not?), how WOULD I have brought those changes in so that they got certs for the X.ctwm branch? I mean, they're SUPPOSED to be on that branch now, right? Shouldn't they be noted as such? -- Matthew Fuller (MF4839) | [EMAIL PROTECTED] Systems/Network Administrator | http://www.over-yonder.net/~fullermd/ On the Internet, nobody can hear you scream.
Re: [ctwm] Crash fix for when WorkSpaces not defined
On Fri 23 Nov 2007 at 03:38:50 -0600, Matthew D. Fuller wrote: Well, no, I'm looking at it in my 'upstream' repo, the same one I push to guardian; it never had the dev branch, only the X.ctwm propagate result. Ah ok, I misunderstood then. I don't have mtn-viz though; I have enough weird languages installed I didn't realise that. on my system already (OCaml? Haskell? What the heck? Is there some weird kool-aid they force-feed you when you start developing a VCS?). But I'm looking at log, and I don't understand why anything would be disconnected. There aren't any breaks in the ancestry chain. log So I tried looking at mtn log, and indeed, the revisions are actually connected. It must be a problem with -viz then. doesn't show anything unusual. So I'm not sure what piece -viz is looking for that's missing. What connecting piece isn't there? Did you look at http://www.falu.nl/~rhialto/monotone.png ? It should show it clearly, I think. Annoying that monotone-viz doesn't show everything - an incorrect visualisation spoils everything... -Olaf. -- ___ Olaf 'Rhialto' Seibert -- You author it, and I'll reader it. \X/ rhialto/at/xs4all.nl-- Cetero censeo authored delendum esse.
Re: [ctwm] Crash fix for when WorkSpaces not defined
On Fri, Nov 23, 2007 at 10:23:09AM +0100 I heard the voice of Rhialto, and lo! it spake thus: Yes, I'd assume it would appear unbroken to you, since you made the commits into your repository. Well, no, I'm looking at it in my 'upstream' repo, the same one I push to guardian; it never had the dev branch, only the X.ctwm propagate result. I don't have mtn-viz though; I have enough weird languages installed on my system already (OCaml? Haskell? What the heck? Is there some weird kool-aid they force-feed you when you start developing a VCS?). But I'm looking at log, and I don't understand why anything would be disconnected. There aren't any breaks in the ancestry chain. log doesn't show anything unusual. So I'm not sure what piece -viz is looking for that's missing. What connecting piece isn't there? -- Matthew Fuller (MF4839) | [EMAIL PROTECTED] Systems/Network Administrator | http://www.over-yonder.net/~fullermd/ On the Internet, nobody can hear you scream.
Re: [ctwm] Crash fix for when WorkSpaces not defined
On Fri 23 Nov 2007 at 02:35:17 -0600, Matthew D. Fuller wrote: Yes, the entire run from a97d0dcc up through 4da549 happened in my private branch. While mtn isn't the way I went for my own stuff, working with a DVCS has well trained me to make throwaway branches for anything that looks likely to take more than 1 commit to do. I'm not sure what viz is showing breakage for, though; eyeballing the ancestry, it's unbroken, and I thought propagate would add on the X.ctwm branch certs. This is the boundaries of my mtn understanding, though. Yes, I'd assume it would appear unbroken to you, since you made the commits into your repository. However in mine, the two are not connected: the older one (a97d0dcc) is the end of the line and the newer one (4da549) is the beginning of a new line. Fortunately it is shown just like when you choose to view only a subset of all revisions. The difference is that there is no way to make them visible since they are not present in my repository. I made a screenshot here: http://www.falu.nl/~rhialto/monotone.png So, given the workflow that you describe, it sounds like monotone should be made to add a sort of short-cut connection between the two unconnected revisions. -Olaf. -- ___ Olaf 'Rhialto' Seibert -- You author it, and I'll reader it. \X/ rhialto/at/xs4all.nl-- Cetero censeo authored delendum esse.
[ctwm] Crash fix for when WorkSpaces not defined
When no WorkSpaces {} are defined in your .ctwmrc, parts of the
structure used to track them aren't initialized properly in the code.
This can lead to crashes when those pointers are dereferenced; I came
across it in the TwmWindows menu. I've pushed up a fix for this;
see attached patch.
I have a sneaky suspicion there are more such land mines scattered
through the code :|
--
Matthew Fuller (MF4839) | [EMAIL PROTECTED]
Systems/Network Administrator | http://www.over-yonder.net/~fullermd/
On the Internet, nobody can hear you scream.
#
#
# patch workmgr.c
# from [cbbb225102a852d23956bec573e7e10b61620c54]
#to [2d59af82aea7cee7cc29bb3db7f77be30fcb3fed]
#
--- workmgr.c cbbb225102a852d23956bec573e7e10b61620c54
+++ workmgr.c 2d59af82aea7cee7cc29bb3db7f77be30fcb3fed
@@ -168,8 +168,14 @@ void ConfigureWorkSpaceManager (void) {
virtualScreen *vs;
for (vs = Scr-vScreenList; vs != NULL; vs = vs-next) {
- WorkSpaceWindow *wsw = (WorkSpaceWindow*) malloc (sizeof
(WorkSpaceWindow));
- wsw-twm_win = (TwmWindow*) 0;
+ /*
+* Make sure this is all properly initialized to nothing. Otherwise
+* bad and undefined behavior can show up in certain cases (e.g.,
+* with no Workspaces {} defined in .ctwmrc, the only defined
+* workspace will be random memory bytes, which can causes crashes on
+* e.g. f.menu TwmWindows.)
+*/
+ WorkSpaceWindow *wsw = (WorkSpaceWindow*) calloc (1, sizeof
(WorkSpaceWindow));
wsw-state = Scr-workSpaceMgr.initialstate; /* BUTTONSSTATE */
vs-wsw = wsw;
}
Re: [ctwm] Crash fix for when WorkSpaces not defined
In message [EMAIL PROTECTED] on Thu, 22 Nov 2007 13:28:25 -0600, Matthew D.
Fuller [EMAIL PROTECTED] said:
fullermd When no WorkSpaces {} are defined in your .ctwmrc, parts of
fullermd the structure used to track them aren't initialized properly
fullermd in the code. This can lead to crashes when those pointers
fullermd are dereferenced; I came across it in the TwmWindows menu.
fullermd I've pushed up a fix for this; see attached patch.
fullermd
fullermd I have a sneaky suspicion there are more such land mines
fullermd scattered through the code :|
Good job. Yeah, I wouldn't be surprised if there are more things like
that...
Ehummm, I think it's time we take a look in the bugs database and try
to fix some of the things (or dismiss it).
Cheers,
Richard
--
Richard Levitte [EMAIL PROTECTED]
http://richard.levitte.org/
When I became a man I put away childish things, including
the fear of childishness and the desire to be very grown up.
-- C.S. Lewis
Re: [ctwm] Crash fix for when WorkSpaces not defined
On Thu, Nov 22, 2007 at 08:44:27PM +0100 I heard the voice of Richard Levitte, and lo! it spake thus: Ehummm, I think it's time we take a look in the bugs database and try to fix some of the things (or dismiss it). Yeah, I was doing a little looking back over bugs and unresolved list posts when I got sidetracked by my Xnest-ed test ctwm blowing up every time I scrolled past my TWM Windows menu entry. Funny how that throws you off your stride. -- Matthew Fuller (MF4839) | [EMAIL PROTECTED] Systems/Network Administrator | http://www.over-yonder.net/~fullermd/ On the Internet, nobody can hear you scream.
Re: [ctwm] Crash fix for when WorkSpaces not defined
Actually, it's less weird than you might think. I assume that Matthew did some hacking in a branch of his own, but since that branch is most probably not among those he's allowed to write to, the revisions themselves come over, but the branch certs do not. So basically, the edge between e07ab7de496e218dc324fe3a9cb66d85dde116d8 and a97d0dcc8eaf6e94ce9190d98913789d9dbbd37f represent the move from the ctwm branch to Matthew's private hackng branch, and the edge between 6eb1af5f822cafe715c4e46f37ea3bc808e7a5f5 and 4da54949171b2cc1c5f467318daf87b683a77d9b represent the move back into the ctwm branch. Cheers, Richard In message [EMAIL PROTECTED] on Fri, 23 Nov 2007 02:00:33 +0100, Rhialto [EMAIL PROTECTED] said: rhialto I pulled a new monotone repository and looked at it with monotone-viz, rhialto and something weird is going on. Maybe it's a monotone bug, or it may be rhialto with monotone-viz. rhialto rhialto There is a Revision: a97d0dcc8eaf6e94ce9190d98913789d9dbbd37f (Add in a rhialto prototype for yyparse() to quiet compiler warnings.) which goes rhialto nowhere (it has a blocked instead of a solid box) and even stranger a rhialto Revision: 6eb1af5f822cafe715c4e46f37ea3bc808e7a5f5 (Move another rhialto twmrc_error_prefix() extern to global scope.) which comes from nowhere. rhialto rhialto Normally the blocked boxes mean that there are connections, but they are rhialto just not shown in the current view. However I think I'm viewing rhialto everything but there is still no link. I suspect there is a link between rhialto these two (maybe even with some intermediary revision) but some bug rhialto prevents me from seeing it. rhialto rhialto My versions are monotone 0.36 (base revision: rhialto e4bc808d89e029ce623f9e8f2b10c84006b83fb5) and monotone-viz 0.15 (base rhialto revision: ) - Please consider sponsoring my work on free software. See http://www.free.lp.se/sponsoring.html for details. -- Richard Levitte [EMAIL PROTECTED] http://richard.levitte.org/ When I became a man I put away childish things, including the fear of childishness and the desire to be very grown up. -- C.S. Lewis
