Menu
▾
▴
meshdb-devel — Technical discussion of Mesh DB development
You can subscribe to this list here.
| 2004 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(4) |
Dec
(2) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2005 |
Jan
(7) |
Feb
(7) |
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2006 |
Jan
|
Feb
|
Mar
|
Apr
(3) |
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Ian L. <il...@us...> - 2006-04-13 05:36:27
|
Sure. The shift file is big so I'll send them separately. It might need word flipping to work on wrong-endian machines as well; I don't recall. Cheers, Ian On Thu, 13 Apr 2006, Brett maxfield wrote: > Hi All, > > Can somebody with access to the web site send me a copy of the files in > lib/* on the website, specifically : > > $SHIFTFILE = "lib/QLD_0900.gsb";/* Shift file */ > $ALTFILE = "lib/alt.desc"; /* Altitude file */ > > If this can be done asap, i can finish testing the node->google earth > script for the website before the weekend. > > Assuming i get that, & i finish testing who can add a page to the itee > mesh site for testing ? > > Alternatively i can just give a file for someone to upload, & i'll test > as a hidden file before linking it into the site. > > I'm using a pre-written function so i expect to work, i just can't run > it locally without the shift/alt data files. > > (need to convert eastings & northings to lat & lon, using the existing > "cvtlatlon" function) > > Cheers > Brett > > > ------------------------------------------------------- > This SF.Net email is sponsored by xPML, a groundbreaking scripting language > that extends applications into web and mobile media. Attend the live webcast > and join the prime developer group breaking into this new coding territory! > http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642 > _______________________________________________ > Meshdb-devel mailing list > Mes...@li... > https://lists.sourceforge.net/lists/listinfo/meshdb-devel > |
|
From: Paul J. <pau...@ja...> - 2006-04-13 05:24:29
|
Ian Lister is only person that has access to the itee web site.=20
=20
I may have a copy that has been ziped up from the server.. will have a =
look for you when I get home!
=20
P
________________________________
From: Brett maxfield [mailto:br...@sp...]
Sent: Thu 13/04/2006 3:11 PM
To: David Leonard
Cc: Paul James; Mes...@li...
Subject: files from web site
Hi All,
Can somebody with access to the web site send me a copy of the files in
lib/* on the website, specifically :
$SHIFTFILE =3D "lib/QLD_0900.gsb";/* Shift file */
$ALTFILE =3D "lib/alt.desc"; /* Altitude file */
If this can be done asap, i can finish testing the node->google earth
script for the website before the weekend.
Assuming i get that, & i finish testing who can add a page to the itee
mesh site for testing ?
Alternatively i can just give a file for someone to upload, & i'll test
as a hidden file before linking it into the site.
I'm using a pre-written function so i expect to work, i just can't run
it locally without the shift/alt data files.
(need to convert eastings & northings to lat & lon, using the existing
"cvtlatlon" function)
Cheers
Brett
|
|
From: Brett m. <br...@sp...> - 2006-04-13 05:12:00
|
Hi All,
Can somebody with access to the web site send me a copy of the files in
lib/* on the website, specifically :
$SHIFTFILE = "lib/QLD_0900.gsb";/* Shift file */
$ALTFILE = "lib/alt.desc"; /* Altitude file */
If this can be done asap, i can finish testing the node->google earth
script for the website before the weekend.
Assuming i get that, & i finish testing who can add a page to the itee
mesh site for testing ?
Alternatively i can just give a file for someone to upload, & i'll test
as a hidden file before linking it into the site.
I'm using a pre-written function so i expect to work, i just can't run
it locally without the shift/alt data files.
(need to convert eastings & northings to lat & lon, using the existing
"cvtlatlon" function)
Cheers
Brett
|
So incorporated nodes would be "active" brismesh members or brismesh owned backbone nodes ? [defining "active" it one or more actual active link(s)] So having public access to encourage interest in brismesh, but incorporated access to help track actual nodes and thier real links? How would "incorporated" nodes be defined (if not above), and how would they be modified ? Cheers Brett David Leonard wrote: > It's something i was playing with/prototyping to show paul. > i didn't cc you on the cnoversation.. should have. > the idea is to have two kinds of data (incorporated|public) > and three kinds of data views: incorporated, public and > incorporated+public. |
|
From: David L. <d...@ad...> - 2005-02-18 08:34:51
|
Double or triple the diameter. Use dark pink (#ff9090), filled sector.
Then re-plot the unfilled arc in the existing grey to give it a softened
edge.
but, for omnis (360deg) - keep it as an unfilled circle at the current
(smaller) radius, thicken the line if that is possible and use
dark pink as the colour.
can you do sectors/filled-arcs in gd? i have to look
d
On Thu, 17 Feb 2005, Brett Maxfield typed thusly:
> If directional antennas show as filled sectors, why not put a larger diameter
> circle outline around the filles sector(s) that indicate direction, to show
> presence of an onmi (no additional circle outline if there is only an omni,
> in which case it would just be a filled circle as before).
>
> IMHO, I think shanging the intensity might be too subtle..
>> On Thu, 17 Feb 2005, Paul James wrote:
>>> Just another suggestion, maybe change the colour of the circle/direction
>>> the antenna is pointing, You can hardly see them!. Maybe a bit darker
>>> grey?
--
David Leonard d...@ad...
Ph:+61 404 844 850
|
It's something i was playing with/prototyping to show paul. i didn't cc you on the cnoversation.. should have. the idea is to have two kinds of data (incorporated|public) and three kinds of data views: incorporated, public and incorporated+public. d On Thu, 17 Feb 2005, Ian Lister typed thusly: > Wow, that's a mega-commit :-) > > What's the intention of the "official style" stuff? > > Cheers, > > Ian > > On Fri, 11 Feb 2005 le...@pr... wrote: >> Update of /cvsroot/meshdb/www/db2 >> In directory sc8-pr-cvs1.sourceforge.net:/tmp/cvs-serv12631 >> >> Modified Files: >> Tag: leonard-dev >> address.html cookies.inc cookies.php create.php edit.php >> elev.php footer.inc gps.php index.php map2d.inc map3b.php >> map4b.php search.php select.php submit.php touch.php >> touchgraph.php util.php view.php >> Added Files: >> Tag: leonard-dev >> official-style.css view-maps.inc.php view-util.inc >> Log Message: >> * Add an extra preference variable "mode", which is either "official", >> "public" or "all" (defaults "official".. for now). >> * Add a new 'official' stylesheet which has a purple theme. This is >> is to visually distinguish between the different modes. It is only >> in effect in 'official' mode (and can't be usurped by stylesheet pref). >> * Correct the cookies.php script so it returns you to the calling page >> when you 'save changes'. It also adds an extra bit to the URL that >> should cause a cache miss, but is otherwise harmless. >> * Add a 'readonly' check inside edit.php >> * Split the overlay map code out into a separate file (still work in progress) >> * Correct index.php's broken overlay map code. >> * Add a debug() function which allows scripts to send messages to >> Apache's error_log. >> * Use the $BINDIR var (from the config file) when finding some programs. >> * Correct bug in overlay map where checkboxes weren't de-checking. >> >> >> --- NEW FILE: official-style.css --- >> >> /* Overrides for 'official' mode. Mostly a purplish color scheme. */ > [snip] > > > > ------------------------------------------------------- > SF email is sponsored by - The IT Product Guide > Read honest & candid reviews on hundreds of IT Products from real users. > Discover which products truly live up to the hype. Start reading now. > http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click > _______________________________________________ > Meshdb-devel mailing list > Mes...@li... > https://lists.sourceforge.net/lists/listinfo/meshdb-devel > -- David Leonard d...@ad... Ph:+61 404 844 850 |
|
From: Brett M. <ma...@sp...> - 2005-02-17 11:10:41
|
If directional antennas show as filled sectors, why not put a larger diameter circle outline around the filles sector(s) that indicate direction, to show presence of an onmi (no additional circle outline if there is only an omni, in which case it would just be a filled circle as before). IMHO, I think shanging the intensity might be too subtle.. Cheers Brett Ian Lister wrote: > On Thu, 17 Feb 2005, Paul James wrote: > >>Just another suggestion, maybe change the colour of the circle/direction >>the antenna is pointing, You can hardly see them!. Maybe a bit darker >>grey? |
|
From: Ian L. <il...@us...> - 2005-02-17 02:38:24
|
On Thu, 17 Feb 2005, Paul James wrote: >Just another suggestion, maybe change the colour of the circle/direction >the antenna is pointing, You can hardly see them!. Maybe a bit darker >grey? Yeah, I was wondering about that. Most nodes that show up still have a full circle (because they haven't entered their spread or direction, or because they have at least one omnidirectional antenna), so we probably don't want to change the colour for everything, but I was thinking perhaps they should have an intensity inversely proportional to the antenna spread (partly to represent a similar amount of signal more focussed, but mostly just to make sure that directional antennas are still as visually apparent as omnidirectional antennas), but then you start wondering whether you should really be using the recorded gain instead... David? Ian |
Wow, that's a mega-commit :-) What's the intention of the "official style" stuff? Cheers, Ian On Fri, 11 Feb 2005 le...@pr... wrote: >Update of /cvsroot/meshdb/www/db2 >In directory sc8-pr-cvs1.sourceforge.net:/tmp/cvs-serv12631 > >Modified Files: > Tag: leonard-dev > address.html cookies.inc cookies.php create.php edit.php > elev.php footer.inc gps.php index.php map2d.inc map3b.php > map4b.php search.php select.php submit.php touch.php > touchgraph.php util.php view.php >Added Files: > Tag: leonard-dev > official-style.css view-maps.inc.php view-util.inc >Log Message: >* Add an extra preference variable "mode", which is either "official", > "public" or "all" (defaults "official".. for now). >* Add a new 'official' stylesheet which has a purple theme. This is > is to visually distinguish between the different modes. It is only > in effect in 'official' mode (and can't be usurped by stylesheet pref). >* Correct the cookies.php script so it returns you to the calling page > when you 'save changes'. It also adds an extra bit to the URL that > should cause a cache miss, but is otherwise harmless. >* Add a 'readonly' check inside edit.php >* Split the overlay map code out into a separate file (still work in progress) >* Correct index.php's broken overlay map code. >* Add a debug() function which allows scripts to send messages to > Apache's error_log. >* Use the $BINDIR var (from the config file) when finding some programs. >* Correct bug in overlay map where checkboxes weren't de-checking. > > >--- NEW FILE: official-style.css --- > >/* Overrides for 'official' mode. Mostly a purplish color scheme. */ [snip] |
|
From: David L. <d...@ad...> - 2005-02-01 13:15:18
|
yeah it did matter to me, since openbsd hasn't c99-ized its stdio
i think (although its using gcc-3)
i commited a change to cast the sizeof to int anyway..
On Mon, 31 Jan 2005, Ian Lister typed thusly:
> On Sat, 29 Jan 2005, David Leonard wrote:
>> On Fri, 28 Jan 2005, il...@pr... typed thusly:
>>> Use the correct format specifier for size_t.
>>
>>> + printf("\t$FMTSZ = %zu;\n", sizeof (struct mail));
>>
>> this is only portable to C99 systems. does that matter?
>
> Not to me, I don't think. Does it to you?
>
> We could add a check in your configure script if you wanted to retain
> portability to older systems...?
>
> Ian
>
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by: IntelliVIEW -- Interactive Reporting
> Tool for open source databases. Create drag-&-drop reports. Save time
> by over 75%! Publish reports on the web. Export to DOC, XLS, RTF, etc.
> Download a FREE copy at http://www.intelliview.com/go/osdn_nl
> _______________________________________________
> Meshdb-devel mailing list
> Mes...@li...
> https://lists.sourceforge.net/lists/listinfo/meshdb-devel
>
--
David Leonard d...@ad...
Ph:+61 404 844 850
|
|
From: Ian L. <il...@us...> - 2005-01-31 03:35:37
|
On Sat, 29 Jan 2005, David Leonard wrote:
>On Fri, 28 Jan 2005, il...@pr... typed thusly:
>> Use the correct format specifier for size_t.
>
>> + printf("\t$FMTSZ = %zu;\n", sizeof (struct mail));
>
>this is only portable to C99 systems. does that matter?
Not to me, I don't think. Does it to you?
We could add a check in your configure script if you wanted to retain
portability to older systems...?
Ian
|
|
From: Ian L. <il...@us...> - 2005-01-16 21:01:28
|
On Sun, 16 Jan 2005, David Leonard wrote: >I think the only thing needed was to network-endianize the index structure... >is that right? Yep, and make the fields fixed size (which I think you've done on your personal dev branch). I think this is accurate, except perhaps not the parenthesised section: >See the structs in src/mailt/index.h (and probably others). They are >mmap()'d in from the index file and accessed directly. Thus their contents >are always in machine endianness. They would need to be converted on read >and write e.g. with ntohl() and friends, which also requires making them >sized types. The current (lack of) type sizing is also a portability >issue, although less difficult to deal with than the endianness. David has >done part of the work on his leonard-dev branch, but I don't know how far >he's got. Ian |
|
From: David L. <d...@ad...> - 2005-01-16 13:15:00
|
I think the only thing needed was to network-endianize the index structure...
is that right?
On Thu, 13 Jan 2005, Tony typed thusly:
> --- Ian Lister <il...@us...> wrote:
>> The mail server is supposed to (but doesn't currently) invoke
>> mailt via
>> procmail to update a mailbox index (mbox.mi) as well as
--
David Leonard d...@ad...
Ph:+61 404 844 850
|
|
From: Ian L. <il...@us...> - 2005-01-13 12:07:10
|
On Thu, 13 Jan 2005, Ian Lister wrote: >I think the only other place is the reading of the index file in >list/index.inc.php, which doesn't appear to be in CVS (David?). I've >attached a copy. Oops.. I didn't look closely enough. Check out src/mailt/mail.inc for the PHP reading side of things. Ian |
|
From: Ian L. <il...@us...> - 2005-01-13 03:02:44
|
On Thu, 13 Jan 2005, Tony wrote: > --- Ian Lister <il...@us...> wrote: >> The mail server is supposed to (but doesn't currently) invoke >> mailt via >> procmail to update a mailbox index (mbox.mi) as well as >> storing the mail >> in a normal mbox. The compute server runs a nightly cron job >> to rebuild >> the index file from the current contents of the mbox. The web >> server just >> reads the index and mbox. > >That's reasonably justifiable, it is a mail ARCHIVE, so it >shouldn't really matter if you can only get messages from it >that are older than 1 day. It would use more CPU cycles just to >update the index each time an email arrives. A live archive is nice. The incremental update mostly works (but isn't being run) but every so often gets mucked up, which is the reason for the nightly rebuild. >What is the command that is run to update the index ? mailt, which is in CVS under src/mailt. >Where is this "leonard-dev" of which you speak ? It's a branch in CVS: http://cvs.sourceforge.net/viewcvs.py/meshdb/?only_with_tag=leonard-dev >There will no doubt be many more questions as I start playing >with this. Also bear in mind that I may look at it, spend a few >days playing with it and then lose interest, I make no promises I know how it is :-) Ian |
|
From: Tony <td_...@ya...> - 2005-01-13 02:39:55
|
--- Ian Lister <il...@us...> wrote: > > The mail server is supposed to (but doesn't currently) invoke > mailt via > procmail to update a mailbox index (mbox.mi) as well as > storing the mail > in a normal mbox. The compute server runs a nightly cron job > to rebuild > the index file from the current contents of the mbox. The web > server just > reads the index and mbox. That's reasonably justifiable, it is a mail ARCHIVE, so it shouldn't really matter if you can only get messages from it that are older than 1 day. It would use more CPU cycles just to update the index each time an email arrives. What is the command that is run to update the index ? > > I think FreeBSD, OpenBSD, Mac OS X, Linux and Solaris all work > either out > of the box or with minimal Makefile hacking. David's autotools > work (on > leonard-dev again) should improve this further, too. Good, I've access to a RH 7.1 box that I'm currently downloading the mbox to (220KB/s download - gotta love fast connections at work !) Where is this "leonard-dev" of which you speak ? There will no doubt be many more questions as I start playing with this. Also bear in mind that I may look at it, spend a few days playing with it and then lose interest, I make no promises :) regards, Tony. ___________________________________________________________ ALL-NEW Yahoo! Messenger - all new features - even more fun! http://uk.messenger.yahoo.com |
|
From: Ian L. <il...@us...> - 2005-01-13 01:57:06
|
On Thu, 13 Jan 2005, Tony wrote: >I would assume that this means that the mail is still being >archived, just that the interface to it is broken ? Yep. >You say that the web server and mail server are different >machines, is the communication between them simply a CGI >transaction ? The mail server is supposed to (but doesn't currently) invoke mailt via procmail to update a mailbox index (mbox.mi) as well as storing the mail in a normal mbox. The compute server runs a nightly cron job to rebuild the index file from the current contents of the mbox. The web server just reads the index and mbox. >I've had a quick look at the CVS and the main interface to the >mail archive is a PHP page that refers to a .htaccess file that >redirects the script to appropriate location. What does this >htaccess file currently look like ? =====8<----- $ cat ~mesh/publicweb/list/.htaccess RedirectMatch msg(.*)\.html http://www.itee.uq.edu.au/~mesh/list/oldmap.php/$1 RedirectMatch msg/([1-9][0-9/]*) http://www.itee.uq.edu.au/~mesh/cgi-bin/view-list.cgi/$1 =====8<----- >Would I be able to setup the mail interface on a machine at my >place and get it to pull the data from the mail server or >wouldn't this work (ie. would a UQ firewall prevent this) ? For development we can probably find a way to get you whatever, but it's not really going to be a goer for deployment. I think the interface you're referring to is just the files on disk, so the only way for you to access those is to have the web server serve up the whole files to you (currently 50MB and 1.3MB for the data and index respectively). >What currently makes the mail store endian specific ? See the structs in src/mailt/index.h (and probably others). They are mmap()'d in from the index file and accessed directly. Thus their contents are always in machine endianness. They would need to be converted on read and write e.g. with ntohl() and friends, which also requires making them sized types. The current (lack of) type sizing is also a portability issue, although less difficult to deal with than the endianness. David has done part of the work on his leonard-dev branch, but I don't know how far he's got. I think the only other place is the reading of the index file in list/index.inc.php, which doesn't appear to be in CVS (David?). I've attached a copy. >Any specific OS that you would recommend it will compile easiest >on ? I think FreeBSD, OpenBSD, Mac OS X, Linux and Solaris all work either out of the box or with minimal Makefile hacking. David's autotools work (on leonard-dev again) should improve this further, too. >Sorry for all the questions, just trying to understand how it >all works. If I have a look at it and figure it out, then I will >also try to add more documentation. Thanks! Ian |
|
From: Paul J. <pau...@ja...> - 2004-12-28 01:22:23
|
Hi, =20 There are areas that the data was not recorded, not all NaN is water. =20 I used this utility to fix the issues that I was having with missing = data. Give it a go, it should resolve the issues you are seeing. =20 http://www.3dnature.com/srtmfill.html =20 Regards, Paul ________________________________ From: Ian Lister [mailto:il...@em...] Sent: Mon 27/12/2004 3:52 PM To: mes...@li... Cc: Paul James Subject: Re: srtm tiles On Tue, 21 Dec 2004, David Leonard wrote: >Ian, I finally managed to get around to making new altitude maps from >SRTM data. I've committed to my dev branch.. if you feel like porting >it to HEAD and building new alt data files, then do so. Fantastic, thanks. The change you're referring to in CVS is src/geo/make-hgt-qt/main.c:1.1.2.2, right? Is there any reason we = wouldn't want that on HEAD? Anyway, I've merged it on to HEAD, and fixed a bug which meant the quadtree covered an extra degree east and north that it didn't need to. This means that the 26-29S/151-154E (3x3) range that covers our area of interest now fits in a 64MB quadtree rather than 256MB, which is handy because the server has a hard VM size resource limit that allows us to = map 64MB in but not 128MB. >You probably want to eval the new data first. I have a db online at > <http://www.adaptive-enterprises.com.au/~mesh/db2/> Cool. The initial impression is certainly of much better data, but there are a few anomalies that we should work out before switching the main = site across. One that jumped out from the nodes already in there is visible = in the elevation diagram between David's place and Paul's: http://www.brismesh.org/db/view.php?nodeid=3D3&peerid=3D1466 = http://www.adaptive-enterprises.com.au/~mesh/db2/view.php?nodeid=3D2&peer= id=3D3 The old data shows Tingalpa Reservoir as being around 20m ASL. The SRTM data has it as NaN, which we can't sensibly interpret as anything other than 0, but is clearly no longer appropriate with the SRTM data. It's kinda nice in the terrain diagram having inland water bodies showing up black, but having that due to them being NaN is not so nice as it leads = to incorrect elevation diagrams as seen in the second URL above. The sea data is more confusing, though. Rather than being a consistent NaN, like the old data is, it varies from a fairly significant distance above sea level to a fairly significant distance below. = http://www.adaptive-enterprises.com.au/~mesh/db2/view.php?nodeid=3D6&zoom= =3D5 Other areas show the sea being as far as 50m below sea level. Perhaps we should do some processing of the SRTM data using the NaN = areas in the old data and the water body information in the VPF database to = set appropriate altitudes for the NaN areas in the SRTM data, and to find = the sea areas to set to 0 or NaN in the SRTM data? Anyway, in the meantime I'll set it up at an alternate URL on the main server so that at least it's accessible for people to play with, and to use with the real database. >merry xmas! i'm heading off early tomorrow morning... Enjoy :-) Ian |
|
From: Ian L. <il...@us...> - 2004-12-27 06:07:05
|
On Tue, 21 Dec 2004, David Leonard wrote: >Ian, I finally managed to get around to making new altitude maps from >SRTM data. I've committed to my dev branch.. if you feel like porting >it to HEAD and building new alt data files, then do so. Fantastic, thanks. The change you're referring to in CVS is src/geo/make-hgt-qt/main.c:1.1.2.2, right? Is there any reason we wouldn't want that on HEAD? Anyway, I've merged it on to HEAD, and fixed a bug which meant the quadtree covered an extra degree east and north that it didn't need to. This means that the 26-29S/151-154E (3x3) range that covers our area of interest now fits in a 64MB quadtree rather than 256MB, which is handy because the server has a hard VM size resource limit that allows us to map 64MB in but not 128MB. >You probably want to eval the new data first. I have a db online at > <http://www.adaptive-enterprises.com.au/~mesh/db2/> Cool. The initial impression is certainly of much better data, but there are a few anomalies that we should work out before switching the main site across. One that jumped out from the nodes already in there is visible in the elevation diagram between David's place and Paul's: http://www.brismesh.org/db/view.php?nodeid=3&peerid=1466 http://www.adaptive-enterprises.com.au/~mesh/db2/view.php?nodeid=2&peerid=3 The old data shows Tingalpa Reservoir as being around 20m ASL. The SRTM data has it as NaN, which we can't sensibly interpret as anything other than 0, but is clearly no longer appropriate with the SRTM data. It's kinda nice in the terrain diagram having inland water bodies showing up black, but having that due to them being NaN is not so nice as it leads to incorrect elevation diagrams as seen in the second URL above. The sea data is more confusing, though. Rather than being a consistent NaN, like the old data is, it varies from a fairly significant distance above sea level to a fairly significant distance below. http://www.adaptive-enterprises.com.au/~mesh/db2/view.php?nodeid=6&zoom=5 Other areas show the sea being as far as 50m below sea level. Perhaps we should do some processing of the SRTM data using the NaN areas in the old data and the water body information in the VPF database to set appropriate altitudes for the NaN areas in the SRTM data, and to find the sea areas to set to 0 or NaN in the SRTM data? Anyway, in the meantime I'll set it up at an alternate URL on the main server so that at least it's accessible for people to play with, and to use with the real database. >merry xmas! i'm heading off early tomorrow morning... Enjoy :-) Ian |
|
From: David L. <d...@ad...> - 2004-11-12 13:29:42
|
RFC1342 in this case.
On Fri, 12 Nov 2004, Ian Lister typed thusly:
> On Mon, 8 Nov 2004 le...@pr... wrote:
>> Update of /cvsroot/meshdb/src/mailt
>
>> Log Message:
>> convert "=?iso-8859-1?q?Tony?" to "Tony" for yahoo emails
>
> I guess it's not a pressing issue for us, but we should probably handle
> that properly. Are you aware of which RFC or whatever describes how text
> encoding is specified in headers?
--
David Leonard d...@ad...
Ph:+61 404 844 850
|
|
From: David L. <d...@ad...> - 2004-11-12 13:20:24
|
On Fri, 12 Nov 2004, Ian Lister typed thusly:
> I think duplication and tracking changes between branches is going to get
> tedious pretty quickly. Are you planning on using your branch for most of
> your development on an ongoing basis? Keeping it closely in sync with
> HEAD, or diverging? We should probably get together again and talk about
> directions at some point soon, I guess.
yes, my idea was to show you what i'm doing by committing on a personal
dev branch, and so you can see what changes i've made, maybe check it
out through my web server, and we can talk about doing mergeing good
bits to to HEAD. i think of you as being in charge of the LIVE tag anyway.
Lets treat HEAD as being 'what will shortly be LIVE'.
btw i am not adverse to ditchin the leonard-dev branch and starting a new
branch again from head if it becomes too stupid a mess.
that tracking commit was probably overkill. but i've been busy again this
last week, so not much has happened, sorry.
--
David Leonard d...@ad...
Ph:+61 404 844 850
|
|
From: Ian L. <il...@us...> - 2004-11-12 00:56:28
|
On Tue, 9 Nov 2004 le...@pr... wrote: >Update of /cvsroot/meshdb/www/db2 >Modified Files: > Tag: leonard-dev > view.php >Log Message: >track r1.17: Use the configured altitude and shift files when running elev. I think duplication and tracking changes between branches is going to get tedious pretty quickly. Are you planning on using your branch for most of your development on an ongoing basis? Keeping it closely in sync with HEAD, or diverging? We should probably get together again and talk about directions at some point soon, I guess. Ian |
|
From: Ian L. <il...@us...> - 2004-11-12 00:50:57
|
On Mon, 8 Nov 2004 le...@pr... wrote: >Update of /cvsroot/meshdb/src/mailt >Log Message: >convert "=?iso-8859-1?q?Tony?" to "Tony" for yahoo emails I guess it's not a pressing issue for us, but we should probably handle that properly. Are you aware of which RFC or whatever describes how text encoding is specified in headers? Ian |
