iamb-dev-internal Mailing List for IAMB -Iamb A Message Board
Status: Beta
Brought to you by:
rbowen
You can subscribe to this list here.
2001 |
Jan
(48) |
Feb
(60) |
Mar
(16) |
Apr
(11) |
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
---|---|---|---|---|---|---|---|---|---|---|---|---|
2002 |
Jan
|
Feb
|
Mar
|
Apr
(1) |
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
From: Rich B. <rb...@rc...> - 2002-04-03 15:54:47
|
For those of you that still care, IAMB has moved again. IAMB will now be developed by CooperMcGregor (my company) and distributed under the Perl dual license, as before. I'm hosting RT, CVS, and mailing lists. We can add other stuff if/as necessary. An IAMB installation seems to make sense too. ;-) Anyways, if you still care about this project, please see http://www.CooperMcGregor.com/products/iamb/ and get on the new mailing lists. I will not be copying over subscribers from one list to the other, so you'll need to get on the list(s) of your own volition. Please direct follow-up discussion to the new mailing lists. -- Rich Bowen - rb...@rc... ReefKnot - http://www.reefknot.org |
From: Rich B. <rb...@rc...> - 2001-04-02 01:20:20
|
Rich Bowen wrote: > > Matt Cashner wrote: > > > > due to some malfunction in this system, my last message is awaiting > > approval. let me try to resend without pissing off the system. > > > > ---- > > > > h3y, c4n w3 m0v3 th!s l!st 0v3r t0 rcb0w3n.c0m (0r r4ther, b4ck 0v3r > > t0)? !'d l!k3 t0 f!n4lly g3t 0ff th3 bl04t3d m3ss that !s s0urc3f0rg3. > > > > h3h3h3. > > m. > > Wow. Can you teach m3 to talk k3wl t0k? > > I'll get a mailing list set up again before I depart for the Left Coast. The following lists are available: iam...@rc... : Replaces this list. It is archived, and I will set up a MHonArc web archive soon. All of you receiving this are already subscribed to that list. (un)subscription is in the usual majordomo manner - send email to maj...@rc... with a message of "(un)subscribe iamb-dev" iam...@rc... : The digest version of this list. Digests are sent out when the total size of accumulated articles reaches a certain size. I don't know what that size is. It appears to be rather large. If you are receiving *this* list in archived format, then you are already subscribed to that new list. iam...@rc... : Messages ot this list go directly into RT. Should this be copied to the -dev mailing list? I have not created any other lists. But if you think that there should be any others, please let me know. And if someone can tell me how to get rid of this annoying ".cf file is out of date" warning, please let me know. I'm *this* close to moving to Postfix. (Hmm. Things like that seem not to work in email. Kinda like tomato, tomato.) -- Rich Bowen <rb...@rc...> Come see me at Apachecon! -- http://www.apachecon.com/ |
From: Rich B. <rb...@rc...> - 2001-04-01 23:59:25
|
Matt Cashner wrote: > > due to some malfunction in this system, my last message is awaiting > approval. let me try to resend without pissing off the system. > > ---- > > h3y, c4n w3 m0v3 th!s l!st 0v3r t0 rcb0w3n.c0m (0r r4ther, b4ck 0v3r > t0)? !'d l!k3 t0 f!n4lly g3t 0ff th3 bl04t3d m3ss that !s s0urc3f0rg3. > > h3h3h3. > m. Wow. Can you teach m3 to talk k3wl t0k? I'll get a mailing list set up again before I depart for the Left Coast. -- Rich Bowen <rb...@rc...> Come see me at Apachecon! -- http://www.apachecon.com/ |
From: Matt C. <su...@qx...> - 2001-04-01 22:46:20
|
due to some malfunction in this system, my last message is awaiting approval. let me try to resend without pissing off the system. ---- h3y, c4n w3 m0v3 th!s l!st 0v3r t0 rcb0w3n.c0m (0r r4ther, b4ck 0v3r t0)? !'d l!k3 t0 f!n4lly g3t 0ff th3 bl04t3d m3ss that !s s0urc3f0rg3. h3h3h3. m. |
From: Matt C. <su...@qx...> - 2001-04-01 22:38:03
|
hey, can we move this list over to rcbowen.com (or rather, back over to)? i'd like to finally get off the bloated mess that is sourceforge. m. |
From: Matt C. <su...@qx...> - 2001-04-01 22:10:25
|
On Sun, 1 Apr 2001, Ken Rietz wrote: > Could it be set up so that the data is saved n (default = 10 for > now) seconds after it is changed? In low-traffic lists, that > could be a considerable savings. Would that mess up the cron > job settings, though? it does that too. after a change request, a timer is added. :) > Yeah. Me, too. Wanna learn together? Wait, we are already > going to be doing that with xxx2sgml and sgml2yyy. (I'm > beginning to wonder is we shouldn't just do xxx2xml and > xml2yyy, but that's a whole new list....) my brane is probably more on a mysql socket client / poe kinda mode right now. but yeah; and xml? cmon fad boy. :) let me get some mailing lists set up and i'll send out info on that and we'll chat there :) > Your what? :-) exactly. ooo shiny thing... m. |
From: Ken R. <kr...@qx...> - 2001-04-01 21:42:49
|
> > Clearly, it depends on two things: the value of n and the length > > of time the data is blocked. We'll probably have to do some fine > > tuning in real life. > > yup yup. right now, its engineered to see if the data needs saved every 10 > seconds. the data will be saved if the queue's modified flag is > set. otherwise, we dont need to waste the cycles or the io. Could it be set up so that the data is saved n (default = 10 for now) seconds after it is changed? In low-traffic lists, that could be a considerable savings. Would that mess up the cron job settings, though? > > More specifically, is it the MySQL DBI, and not another one > > that we could possibly use? Are there any serious alternatives: > > free, stable, easily obtained, and standardized? > > its DBI in general. tim and the gang didnt think the core all the way > through to threading. i am further told that libmysqlclient.a (the > standard client library to interface to mysql) is ALSO not > thread-happy. so we're screwed on both fronts. i suppose we could write a > thread-happy interface to mysql. oh wait. i really am not that > high. :) its an idea but so beyond my depth and breadth. Yeah. Me, too. Wanna learn together? Wait, we are already going to be doing that with xxx2sgml and sgml2yyy. (I'm beginning to wonder is we shouldn't just do xxx2xml and xml2yyy, but that's a whole new list....) > > I also am interested to see how this works out. Glad to see that > > you are back at this! > > yeah. its nice to be writing good code in a pretty stressfree situation > for once :) if i can get my attention span back, we'll be set :) Your what? :-) -- Ken |
From: Matt C. <su...@qx...> - 2001-04-01 17:09:46
|
On Sun, 1 Apr 2001, Ken Rietz wrote: > A hash ref? A scalar? Do you mean that you would create a hash, > and both the hash and a ref to it would get stored? Could you > re-create the hash from the database from just the ref? > > Something is really not clicking here. i'm not storing the ref you silly monkey. i'm storing the data in the ref. the ref is just a convienent way to pass data around. > Clearly, it depends on two things: the value of n and the length > of time the data is blocked. We'll probably have to do some fine > tuning in real life. yup yup. right now, its engineered to see if the data needs saved every 10 seconds. the data will be saved if the queue's modified flag is set. otherwise, we dont need to waste the cycles or the io. > More specifically, is it the MySQL DBI, and not another one > that we could possibly use? Are there any serious alternatives: > free, stable, easily obtained, and standardized? its DBI in general. tim and the gang didnt think the core all the way through to threading. i am further told that libmysqlclient.a (the standard client library to interface to mysql) is ALSO not thread-happy. so we're screwed on both fronts. i suppose we could write a thread-happy interface to mysql. oh wait. i really am not that high. :) its an idea but so beyond my depth and breadth. > I also am interested to see how this works out. Glad to see that > you are back at this! yeah. its nice to be writing good code in a pretty stressfree situation for once :) if i can get my attention span back, we'll be set :) m. |
From: Ken R. <kr...@qx...> - 2001-04-01 16:48:38
|
Rich Bowen wrote: > > Matt Cashner wrote: > > > > the decision i've made for the internals of the stree daemon is to store > > the strees in an internal hash ref. A hash ref? A scalar? Do you mean that you would create a hash, and both the hash and a ref to it would get stored? Could you re-create the hash from the database from just the ref? Something is really not clicking here. > > then every n seconds a snapshot of > > that internal queue will be taken and written to the > > database. modification of the hash should be fast enough to avoid data > > collisions (extensive testing will verify this). i'm probably going to > > need another process to farm off the database saving too. DBI blocks IO > > and as such, while DBI is doing a insert or whatever, the whole server has > > to sit and spin until the IO is done. very silly and very nasty. and if we > > plan on this being used in a high traffic situation, that sort of blocking > > could be very ugly indeed. any thoughts folks? Clearly, it depends on two things: the value of n and the length of time the data is blocked. We'll probably have to do some fine tuning in real life. Since the value of n is a function of the stability of the server (and the platform), maybe we should say in the docs that the default value of n needs to be divided by 10 for Win*. :-) > Is this DBI's fault, or the particular DBD that we happen to be using? > Would another database alleviate this problem? (I seem to recall that > this is DBI, but I was not sure.) More specifically, is it the MySQL DBI, and not another one that we could possibly use? Are there any serious alternatives: free, stable, easily obtained, and standardized? > But, yes, it would be pretty cool to have a dbi cache thingy that you > send data to, and it queues up inserts/updates for later processing. > This could be a very cool thing just of itself - that is, completely > apart from IAMB. I also am interested to see how this works out. Glad to see that you are back at this! -- Ken |
From: Matt C. <su...@qx...> - 2001-04-01 16:43:23
|
On Sun, 1 Apr 2001, Rich Bowen wrote: > Is this DBI's fault, or the particular DBD that we happen to be using? > Would another database alleviate this problem? (I seem to recall that > this is DBI, but I was not sure.) its a dbi problem. another symptom of this is that the dbi engine can only handle one statement at a time. its not a database limitation, obviously, but a flaw in the core of dbi. solutions we've kicked around are rewriting dbi (do i really look that high?) and a proxy to dbi (what i've just proposed here). when perl6 comes out and threading is the default, dbi will have to be totally rewritten to properly support threading, at which time this limitation between poe and dbi will go away. > But, yes, it would be pretty cool to have a dbi cache thingy that you > send data to, and it queues up inserts/updates for later processing. > This could be a very cool thing just of itself - that is, completely > apart from IAMB. yeah. esp for some other more adequately funded projects :) i'm going to write a very iamb specific model and then ponder generalizing it for other fun and evil purposes. m. |
From: Rich B. <rb...@rc...> - 2001-04-01 15:36:28
|
Matt Cashner wrote: > > the decision i've made for the internals of the stree daemon is to store > the strees in an internal hash ref. then every n seconds a snapshot of > that internal queue will be taken and written to the > database. modification of the hash should be fast enough to avoid data > collisions (extensive testing will verify this). i'm probably going to > need another process to farm off the database saving too. DBI blocks IO > and as such, while DBI is doing a insert or whatever, the whole server has > to sit and spin until the IO is done. very silly and very nasty. and if we > plan on this being used in a high traffic situation, that sort of blocking > could be very ugly indeed. any thoughts folks? Is this DBI's fault, or the particular DBD that we happen to be using? Would another database alleviate this problem? (I seem to recall that this is DBI, but I was not sure.) But, yes, it would be pretty cool to have a dbi cache thingy that you send data to, and it queues up inserts/updates for later processing. This could be a very cool thing just of itself - that is, completely apart from IAMB. -- Rich Bowen <rb...@rc...> Come see me at Apachecon! -- http://www.apachecon.com/ |
From: Matt C. <su...@qx...> - 2001-04-01 15:19:37
|
the decision i've made for the internals of the stree daemon is to store the strees in an internal hash ref. then every n seconds a snapshot of that internal queue will be taken and written to the database. modification of the hash should be fast enough to avoid data collisions (extensive testing will verify this). i'm probably going to need another process to farm off the database saving too. DBI blocks IO and as such, while DBI is doing a insert or whatever, the whole server has to sit and spin until the IO is done. very silly and very nasty. and if we plan on this being used in a high traffic situation, that sort of blocking could be very ugly indeed. any thoughts folks? m. |
From: Ken R. <kr...@qx...> - 2001-03-07 13:50:21
|
Matt Cashner wrote: > > ok. it will be a while before i can get testable code into cvs. the short > version of the story is this: i am having blood sugar problems that may be > diabetes setting in. or it might just be stress. or it might be aliens > controlling my brane again. but either way, i'm not feeling great and my > thought pattern isnt the most coherent (as my cow-orkers can attest > to). you really dont want the code i've tried to write in the last few > days. so i'm taking a break from a lot of things and focusing on getting > better. doctors appt soon and we'll see then. sorry about the delays. i > way get around to committing a small patch to Stree.pm since that's stable > and good code. *shrug* anyway, that's the story (the sort of short > version :P) > OOG. Forget coding on Strees for a while. It's much more important that you get better. I'll be praying for you. -- Ken |
From: Rich B. <rb...@rc...> - 2001-03-07 12:54:16
|
Matt Cashner wrote: > > ok. it will be a while before i can get testable code into cvs. the short > version of the story is this: i am having blood sugar problems that may be > diabetes setting in. or it might just be stress. or it might be aliens > controlling my brane again. but either way, i'm not feeling great and my > thought pattern isnt the most coherent (as my cow-orkers can attest > to). you really dont want the code i've tried to write in the last few > days. so i'm taking a break from a lot of things and focusing on getting > better. doctors appt soon and we'll see then. sorry about the delays. i > way get around to committing a small patch to Stree.pm since that's stable > and good code. *shrug* anyway, that's the story (the sort of short > version :P) Wow. That sucks. Keep us updated. -- Rich Bowen <rb...@rc...> Come see me at Apachecon! -- http://www.apachecon.com/ |
From: Matt C. <su...@qx...> - 2001-03-07 05:11:23
|
ok. it will be a while before i can get testable code into cvs. the short version of the story is this: i am having blood sugar problems that may be diabetes setting in. or it might just be stress. or it might be aliens controlling my brane again. but either way, i'm not feeling great and my thought pattern isnt the most coherent (as my cow-orkers can attest to). you really dont want the code i've tried to write in the last few days. so i'm taking a break from a lot of things and focusing on getting better. doctors appt soon and we'll see then. sorry about the delays. i way get around to committing a small patch to Stree.pm since that's stable and good code. *shrug* anyway, that's the story (the sort of short version :P) |
From: Matt C. <su...@qx...> - 2001-03-05 03:57:15
|
On Sat, 3 Mar 2001, Matt Cashner wrote: > well? if so, i can probably have something semi functional sunday night or not coming tonight. medical type situation. sorry. m. |
From: Ken R. <kr...@qx...> - 2001-03-04 05:30:56
|
Matt Cashner wrote: > > so are you +1 on the matt worrying about silly socket munging protocol as > well? if so, i can probably have something semi functional sunday night or > so. I'm all for letting you have at it. Make that puppy sing. -- Ken |
From: Matt C. <su...@qx...> - 2001-03-04 03:28:46
|
On Sat, 3 Mar 2001, Ken Rietz wrote: > My milli-tuits have been completely plunged into PFH. i figured :) > Gotcha. Internal TCP. I have read about it, but it tends to be > a really minor issue, and it had scuttled off to a back corner > of my mind and hidden really well. its easy stuff. open socket. print stuff. read stuff. close socket. but anywho... so are you +1 on the matt worrying about silly socket munging protocol as well? if so, i can probably have something semi functional sunday night or so. m. |
From: Ken R. <kr...@qx...> - 2001-03-04 01:52:37
|
Matt Cashner wrote: > > On Sat, 3 Mar 2001, Ken Rietz wrote: > > > My understanding of sockets doesn't square with your usage of > > the term. For me, a socket is an IP address plus a port, used > > in TCP communications. What's a socket to you? I expect it is > > more general. > > that's exactly what i'm talking about. someone hasnt done a cvs update in > a whlie :) My milli-tuits have been completely plunged into PFH. > why tcp sockets? because no matter what platform this is on, we can be > guaranteed of a tcp socket, even if just on the loopback. we cant be > guaranteed of having unix socket ability. Gotcha. Internal TCP. I have read about it, but it tends to be a really minor issue, and it had scuttled off to a back corner of my mind and hidden really well. -- Ken |
From: Matt C. <su...@qx...> - 2001-03-03 21:11:06
|
On Sat, 3 Mar 2001, Ken Rietz wrote: > My understanding of sockets doesn't square with your usage of > the term. For me, a socket is an IP address plus a port, used > in TCP communications. What's a socket to you? I expect it is > more general. that's exactly what i'm talking about. someone hasnt done a cvs update in a whlie :) in the scripts directory you will find B<streed>. the cvs version listens on port 11211 (real port to be determined later) and echos back whatever you say to it. pretty simple. why tcp sockets? because no matter what platform this is on, we can be guaranteed of a tcp socket, even if just on the loopback. we cant be guaranteed of having unix socket ability. m. |
From: Ken R. <kr...@qx...> - 2001-03-03 18:35:11
|
Matt Cashner wrote: > > On Sat, 3 Mar 2001, Ken Rietz wrote: > > > I guess I need to know what you have planned for B<streed>. > > <blank stare> > > have we not talked about this before? B<streed> is the daemon which > handles atomic updates to the strees so we dont have to worry about data > collisions. Yeah, I knew that. But I wasn't sure what besides the strees B<streed> was going to be working with. Are you planning, for example, to have any other bookkeeping stuff, like next/last update times, and is any of it going to be disk-based? That "other" sort of stuff that wouldn't have shown up yet. > like i said in my email of last night, the language i'm looking for > direction on is the language which the sockets will communicate with > each other via. this is low level stuff here. yes, the high level API > will mimic IAMB::Stree. my concern right now is the low level, socket > level, commands. My understanding of sockets doesn't square with your usage of the term. For me, a socket is an IP address plus a port, used in TCP communications. What's a socket to you? I expect it is more general. -- Ken |
From: Rich B. <rb...@rc...> - 2001-03-03 18:06:24
|
Matt Cashner wrote: > > On Fri, 2 Mar 2001, Rich Bowen wrote: > > > select * from streed where timestamp > $time > > we're talking to a socket here. the query language i'm looking for is for > the API module to talk to the socket. when can make the API to the socket > do anything you want on the user end. kernel end however i'm not sure we > want to go that direction. i was thinking something very simple like > > STREE 1 > ^ get stree for forumID 1 > > ADD 1 5[6] > ^ ADD ArticleID 6 as a child of article 5 in forumID 1 > > DEL 1 6 > ^ delete article 6 from forumID 1 > > etc etc. you get the direction i'm going i gather. Yes, we're going for brevity, rather than descriptiveness. Not sure what else has to be done beyond list, add, and delete. Unless there a BURN command that deletes EVERYTHING! Mwuhahahahahaaha! But seriously, seems pretty thorough. -- Rich Bowen <rb...@rc...> Come see me at Apachecon! -- http://www.apachecon.com/ |
From: Rich B. <rb...@rc...> - 2001-03-03 17:55:02
|
Matt Cashner wrote: > > Whatever data B<streed> might create for its own use can have > > any API your little ol' heart desires. Consistency would be > > nice, but that has never stopped me. :-) > > ok. that's what i'm looking for. everyone else feel this way? if you all > do, i can probably get a pre-alpha out in the next day or so. otherwise, > i cannot continue until i have a socket-level command language approved. +1 And, installing DBD::RAM right now. -- Rich Bowen <rb...@rc...> Come see me at Apachecon! -- http://www.apachecon.com/ |
From: Matt C. <su...@qx...> - 2001-03-03 15:25:12
|
On Sat, 3 Mar 2001, Ken Rietz wrote: > I guess I need to know what you have planned for B<streed>. <blank stare> have we not talked about this before? B<streed> is the daemon which handles atomic updates to the strees so we dont have to worry about data collisions. > If it accesses the same data that B<stree> does, is there any > reason not to use the same API? (I did leave some blanks for > B<streed> to fill in, but the whole thing is so simple that > mimicking should be trivial.) like i said in my email of last night, the language i'm looking for direction on is the language which the sockets will communicate with each other via. this is low level stuff here. yes, the high level API will mimic IAMB::Stree. my concern right now is the low level, socket level, commands. > Whatever data B<streed> might create for its own use can have > any API your little ol' heart desires. Consistency would be > nice, but that has never stopped me. :-) ok. that's what i'm looking for. everyone else feel this way? if you all do, i can probably get a pre-alpha out in the next day or so. otherwise, i cannot continue until i have a socket-level command language approved. > I'll snag DBD::RAM from CPAN sometime soon. :) m. |
From: Ken R. <kr...@qx...> - 2001-03-03 14:40:19
|
Matt Cashner wrote: > > i'm working on the guts of B<streed> and it suddenly occurs to me that i > have no language defined for speaking to the server. now, it could be that > you all leave it up to me and i build the daemon and a module to speak to > the daemon and no one really cares as long as it works. but i figure you > all actually want some input. so, what kind of commands should the server > accept on a socket and what sort of spooge should it emit? > > and as a word of preparation, i'm using the uber cool DBD::RAM for RDBMS > emulation in testing, so when i release a pre-alpha of this, you'll want > to make sure you have DBD::RAM installed :) I guess I need to know what you have planned for B<streed>. If it accesses the same data that B<stree> does, is there any reason not to use the same API? (I did leave some blanks for B<streed> to fill in, but the whole thing is so simple that mimicking should be trivial.) Whatever data B<streed> might create for its own use can have any API your little ol' heart desires. Consistency would be nice, but that has never stopped me. :-) I'll snag DBD::RAM from CPAN sometime soon. -- Ken |