Menu
▾
▴
lilycore-dev — The development of the lilyCore project will be discussed here.
You can subscribe to this list here.
| 2001 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(2) |
Dec
|
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2002 |
Jan
|
Feb
(9) |
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
(2) |
Sep
|
Oct
(17) |
Nov
(2) |
Dec
(2) |
| 2003 |
Jan
|
Feb
|
Mar
(9) |
Apr
(1) |
May
|
Jun
|
Jul
|
Aug
(3) |
Sep
|
Oct
|
Nov
|
Dec
|
| 2004 |
Jan
(1) |
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
(1) |
Aug
|
Sep
|
Oct
|
Nov
(1) |
Dec
(1) |
| 2005 |
Jan
|
Feb
|
Mar
(4) |
Apr
|
May
(2) |
Jun
(2) |
Jul
(3) |
Aug
(2) |
Sep
(6) |
Oct
(6) |
Nov
|
Dec
|
| 2006 |
Jan
|
Feb
(1) |
Mar
(1) |
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Christian R. <lil...@ce...> - 2002-10-08 10:43:14
|
Allen, Good eye. The documentation is, in fact, 100% correct. The implementation is wrong. The verb which processes the message is using the 'opt' variable rather than the 'optname' variable, which results in this strange behavior. This ticket is marked as a bug and moved to the open bucket. christian > User: [#121] prisoner > MOO: 1.8.1+g1+s > Core: lily running rev 2.6.2 > Server Time: Fri Aug 30 08:51:29 2002 EDT > ---%report%---- > The documentation for the #$# optiosn command at > http://lilycore.sourceforge.net/ClientOptions.html > states > login: #$# options +sender +sendgroup +recip_regexp +blat > %options -blat +sender +sendgroup +recip_regexp > > but this is incorrect. a test actually shows > #$# options +blat > %options -+blat > ---%report%---- > > |
|
From: Christian R. <lil...@ce...> - 2002-10-08 10:29:31
|
Allen, I added a paragraph to the ClientMessages.html doc telling the developer that only the #$# ping and #$# options messages can be sent prior to login. The docs will be published some time today. christian > User: [#121] prisoner > MOO: 1.8.1+g1+s > Core: lily running rev 2.6.2 > Server Time: Fri Oct 4 13:17:59 2002 EDT > ---%report%---- > There is no indication that #$# client cannot be entered before > the user logs in. > ---%report%---- > > |
|
From: Christian R. <lil...@ce...> - 2002-10-08 00:55:55
|
Allen, I corrected the documentation. Thanks for pointing this out. -christian > User: [#121] prisoner > MOO: 1.8.1+g1+s > Core: lily running rev 2.6.2 > Server Time: Sat Aug 10 19:41:45 2002 EDT > ---%report%---- > The documentation at > > http://lilycore.sourceforge.net/lilyCore%20Client%20Options.html > > indicates that %whoami will either be sent "near the end of the > login process" or "immediately in response". > > The implementation, and the functionality that clily appears to > depend on, is that for any "relevant" user change (where "relevant" > isn't defined) a new %whoami is sent reflecting this change. > > Request that the documentation be changed to reflect the implementation. > ---%report%---- > > |
|
From: Christian R. <lil...@ce...> - 2002-10-08 00:43:36
|
Allen, I think the results of that discussion were profoundly negative. #$# who and #$# what are pretty much not working right, and clients should probably not use those features at this point. If you have a more positive recollection, please let me know. christian > User: [#121] prisoner > MOO: 1.8.1+g1+s > Core: lily running rev 2.6.2 > Server Time: Fri Aug 9 17:00:47 2002 EDT > ---%report%---- > The documentation at > http://lilycore.sourceforge.net/lilyCore%20Client%20Messages.html > reports that these commands are unimplemented, but there has > been great discussion about them and they appear to do something, > sometimes. > ---%report%---- > > |
|
From: Christian R. <lil...@ce...> - 2002-10-08 00:27:53
|
Chris, How right you are! This is both a bug in the server and bad advice in the docs. I have updated the docs to note the bug and disuade people from registering for SLCP post login. I have also noted the bug and moved it to the 'open' tickets box. The changed docs will be published tomorrow. -christian > User: [#2689] chris > MOO: 1.8.1+g1+s > Core: lily running rev 2.6.2 > Server Time: Mon Nov 5 02:27:13 2001 EST > ---%report%---- > the documentation in the client writers guide for leaf-notify/slcp claims > you can set the option after login and then request an #$# slcp-sync. This > is not the case. minor, but I ran into it in writing a client and thought > I could turn it on after the fact. > ---%report%---- > > |
|
From: Christian R. <lil...@ce...> - 2002-10-08 00:16:00
|
Chris, This has been corrected. At the same time I added the 'memo' attribute and cleared up the attributes documentation. This content will be published some time tomorrow. christian > User: [#2689] chris > MOO: 1.8.1+g1+s > Core: lily running rev 2.6.2 > Server Time: Wed Sep 26 04:25:41 2001 EDT > ---%report%---- > Summary really says it all. Rufus Xavier Sarsparilla would be at a loss... > ---%report%---- > > |
|
From: Christian R. <lil...@ce...> - 2002-10-07 23:57:57
|
The attribute names can be in any case, though they are generally depicted in upper case. I have added clarification the documentation, which will be republished tomorrow. -christian > User: [#2689] chris > MOO: 1.8.1+g1+s > Core: lily running rev 2.6.2 > Server Time: Wed Sep 26 02:47:33 2001 EDT > ---%report%---- > The docs aren't clear on whether attribute names in SLCP events are > guaranteed to be in upper case or could be in any case > ---%report%---- > > |
|
From: Christian R. <lil...@ce...> - 2002-10-07 23:40:52
|
I have updated the docs, watch lily-dev for publication details. -christian > User: [#121] prisoner > MOO: 1.8.1+g1+s > Core: lily running rev 2.6.2 > Server Time: Sun Jul 8 08:10:11 2001 EDT > ---%report%---- > http://docs.lily.org/option.htm is missing documentation for the > following options: > recip > slcp > whoami > prompt2 > version > slcpjr > jabber > slcp-name > tcpnodelay > > Additionally, the documentation states: > Whenever you set options the > server will reply to you with %options followed by +optionname > for options successfully or currently enabled, and -optionname for those > options unsupported by this server. > > Yet this is not followed by, at least, the +version option. > ---%report%---- > > |
|
From: Christian R. <lil...@ce...> - 2002-10-07 13:56:13
|
Ron, This has been fixed in 2.6.4-cr6 and is slated for inclusion in 2.8, due out this week. Thanks for the report, this was easy to fix! christian > User: [#109] maker > MOO: 1.8.1+g1+s > Core: lily running rev 2.6.2 > Server Time: Sun Sep 1 19:49:43 2002 EDT > ---%report%---- > When typing the command "/game ohell", I got the following traceback: > #2:/game, line 11: Property not found > .. called from #6:do_command (this == #109), line 32 > .. called from #0:do_command, line 5 > ---%report%---- > > |
|
From: Christian R. <lil...@ce...> - 2002-10-07 13:41:38
|
Chris, Thanks very much for this problem report. I fixed this a few minutes ago and will be releasing it presently as 2.6.4-cr6. The fix is slated for inclusion in 2.8, due this week. To get this fix applied to RPI, please talk to Matt (Achorrath). christian > User: [#2689] chris > MOO: 1.8.1+g1+s > Core: lily running rev 2.6.2 > Server Time: Sat Oct 5 22:33:16 2002 EDT > ---%report%---- > Although memo is documented to not yet be implemented, it probably should > be there. That part aside, I have no info set. I do have finger information. > The only thing in my ATTRIB is this: ATTRIB=4=info - That didn't show up for > me until I set both memo and finger information. I haven't tried it with just > trying to set finger info yet. It may be that either a test is reversed or > a flag isn't getting set right. While whoever's in there is working on this > getting memo working would be great, too. ;) > Thanks! > ---%report%---- > > |
|
From: Christian R. <lil...@ce...> - 2002-08-21 14:37:44
|
Damien, I cannot replicate this problem on 2.6.4-cr3. Here is what I see within tlily: Hiram: /appoint xian test owner (you have offered Xian ownership of discussion test) Xian: (you have accepted ownership of discussion test) /appoint me test owner (you have accepted ownership of discussion test) Hiram: (you have offered Xian ownership of discussion test) Xian: /appoint hiram test owner (you have offered Hiram ownership of discussion test) Hiram: (you have accepted ownership of discussion test) /appoint me test owner (you have accepted ownership of discussion test) Xian: [this _should_ be blank if I cannot replicate the bug] (you have offered Hiram ownership of discussion test) Any suggestions? Am I doing something wrong here? christian |
|
From: Christian R. <lil...@ce...> - 2002-08-17 20:41:44
|
I cannot replicate this problem in 2.6.4-cr3. I can see the 'STAMP' flag in the SLCP event and the physical timestamp in the text-mode interface. It could well have been fixed at some point in the past. -christian |
|
From: Will C. <wc...@in...> - 2002-02-27 20:43:56
|
# -> (14:36) From Coke, to lily-dev: # - patches against http://lily.acm.rpi.edu:7780/code/command_mode/%2Fhow # # -> (15:32) From Nautilus [@home][whee.], to Coke, lily-dev: # - Add "disclist = {};" after current line 25. Add "disclist = listinsert(dis # - clist,length(p.memb));" after current line 31. Add "disclist = $list_utils # - :scalarSort(disclist);" after current line 49. (For what it's worth, it # - appears that a logged-out player can still be a pig yet not included in # - the average Suck.) Add "player:notify("The median discussion membership # - is " + tostr( usersTotal%2 ? disclist[(usersTotal/2)+1] | (disclist[(usersT # - otal/2)]+disclist[(usersTotal/2)+1])/2) + " users.");" after the previous # - added line (the one with scalarSort). # # -> (15:34) From Nautilus [@home][whee.], to lily-dev: # - And if you'd rather say "disclist = (@disklist, length(p.memb));" instead # - of the listinsert line, feel free. It all comes out in the sort. # # -> (15:35) From Nautilus [@home][whee.], to lily-dev: # - Thanks to Achorrath for the help with the scalarSort function. # # -> (15:39) From Coke, to lily-dev: # - cool. can you send that to lil...@li... ? |
|
From: Josh W. <jo...@hi...> - 2002-02-21 23:45:40
|
At 16:27 on 02/21/2002 EST, "Will Coleda" <wc...@in...> wrote: > Will Coleda wrote: > > So, my plan is to take RPI, get rid of all the wierd code (like the /how > > code that was special cased for a particular user on RPI that I pulled > > today), pull all the updates from devCore that are stable enough (or > > small enough) to save, and then archive that devCore. > > Speaking of which, the following people have claimed bugs on jitterbug: > > http://www.centauri.org/cgi-bin/lily > > wilmesj: #81, #84, #336, #395 81 is basically a reminder to go back and remove some code which isn't used any more. I am pretty sure it's safe to do so at this point, since I think selfEventMsg has been in use @ rpi for a while now, and nobody's complained. Give me a stable devcore and i'd be happy to make the change and close the case. 84, #336, and #395 i hand't done anything on, so i've un-claimed them and moved them back to "open". --Josh > newbeb: #52, #177, #262 > gad: #103, #376 > coke: [list elided] > albert: #223, #396, #397 > > Can I get a status report on these bugs? > > Also, can we get stroke (cc'd on this message) a jitterbug account, as > he's volunteered to take care of the help system? > > _______________________________________________ > lilycore-dev mailing list > lil...@li... > https://lists.sourceforge.net/lists/listinfo/lilycore-dev |
|
From: Will C. <wc...@in...> - 2002-02-21 21:28:03
|
Will Coleda wrote: > So, my plan is to take RPI, get rid of all the wierd code (like the /how > code that was special cased for a particular user on RPI that I pulled > today), pull all the updates from devCore that are stable enough (or > small enough) to save, and then archive that devCore. Speaking of which, the following people have claimed bugs on jitterbug: http://www.centauri.org/cgi-bin/lily wilmesj: #81, #84, #336, #395 newbeb: #52, #177, #262 gad: #103, #376 coke: [list elided] albert: #223, #396, #397 Can I get a status report on these bugs? Also, can we get stroke (cc'd on this message) a jitterbug account, as he's volunteered to take care of the help system? |
|
From: Will C. <wc...@in...> - 2002-02-21 21:18:54
|
Josh Wilmes wrote: > > While porting these things over IS helpful, it does remove some of the > pressure for ever getting the core to a real "release" state. > > IMHO, there should be planned releases for specific upcoming features, and > RPI should really be upgrading along with everyone else. I don't think > it's good for lily to have RPI running a "weird" core. These updates are actually part of a plan to get RPI running a non-weird core. Because devCore current contains so many unfinished projects, it's not very useful going forward, because it's unlikely a new release -can- be cut by those of us remaining. So, my plan is to take RPI, get rid of all the wierd code (like the /how code that was special cased for a particular user on RPI that I pulled today), pull all the updates from devCore that are stable enough (or small enough) to save, and then archive that devCore. Then, cut a new core using RPI as the base. > And if people get whiny (myself included) about some feature which is > already fixed not being on the RPI core yet, they can do what users on any > other lily core would do- ask for an upgrade. This encourages the devcore > to stay reasonably stable so that releases CAN be made, as well. > > If someone's doing MAJOR surgery which won't be finished in a few days, > they should do the equivalent of what people do in any other open source > project. Check out the core and driver, run it on their own machine, and > submit a patch. > > Just my 2 cents. Yup. Agreed. Comments on my plan of attack more than welcome. |
|
From: Josh W. <jo...@hi...> - 2002-02-21 17:56:17
|
While porting these things over IS helpful, it does remove some of the pressure for ever getting the core to a real "release" state. IMHO, there should be planned releases for specific upcoming features, and RPI should really be upgrading along with everyone else. I don't think it's good for lily to have RPI running a "weird" core. And if people get whiny (myself included) about some feature which is already fixed not being on the RPI core yet, they can do what users on any other lily core would do- ask for an upgrade. This encourages the devcore to stay reasonably stable so that releases CAN be made, as well. If someone's doing MAJOR surgery which won't be finished in a few days, they should do the equivalent of what people do in any other open source project. Check out the core and driver, run it on their own machine, and submit a patch. Just my 2 cents. --Josh At 9:15 on 02/21/2002 PST, "William J. Coleda" <lil...@ce...> wrote: > Fixed on devCore ages ago. ported to RPI. > > Added "Average User is in" for grins, since I was in there. > > Users: 1 Here; 1 Away; 9 Detached; 8 Max > Discs: 6 Public; 2 Private; 18 Max > 22 Player Objects; 82 Buckets > There are 3 accounts unused for more than one year. > Coke is in 5 discussions. (you pig) > The average user is in 2 discussions. > You own 2 of the infinite discussions you are allowed to create/own. > > > User: [#127] coke > > MOO: 1.8.1+g1+s > > Core: lily running rev 2.6.2 > > Server Time: Tue Nov 6 23:26:33 2001 EST > > ---%report%---- > > If you are the pig, then the line > > You are in 319 discussions; Coke is in 319 discussions. > > Is tres redundant. Should be easy enough to skip the "Coke is" if you are > > Coke. Perhaps tamenamenuc (sp?) could be used here. > > ---%report%---- > > > > > > _______________________________________________ > lilycore-dev mailing list > lil...@li... > https://lists.sourceforge.net/lists/listinfo/lilycore-dev |
|
From: William J. C. <lil...@ce...> - 2002-02-21 17:15:33
|
Fixed on devCore ages ago. ported to RPI. Added "Average User is in" for grins, since I was in there. Users: 1 Here; 1 Away; 9 Detached; 8 Max Discs: 6 Public; 2 Private; 18 Max 22 Player Objects; 82 Buckets There are 3 accounts unused for more than one year. Coke is in 5 discussions. (you pig) The average user is in 2 discussions. You own 2 of the infinite discussions you are allowed to create/own. > User: [#127] coke > MOO: 1.8.1+g1+s > Core: lily running rev 2.6.2 > Server Time: Tue Nov 6 23:26:33 2001 EST > ---%report%---- > If you are the pig, then the line > You are in 319 discussions; Coke is in 319 discussions. > Is tres redundant. Should be easy enough to skip the "Coke is" if you are > Coke. Perhaps tamenamenuc (sp?) could be used here. > ---%report%---- > > |
|
From: William J. C. <lil...@ce...> - 2002-02-21 17:05:22
|
Fixed on devCore ages ago, now ported to RPI. > User: [#442] jeffro > MOO: 1.8.1+g1+s > Core: lily running rev 2.6.2 > Server Time: Thu Nov 8 11:10:31 2001 EST > ---%report%---- > it is common to type foo:?blah blah blah? > this results in there being 2 ?s at the end of the resulting send, > can the following logic be added to this code such that: > if there exists a ? at the end of the string it should be stripped off > > thank you > ---%report%---- > > |
|
From: William J. C. <lil...@ce...> - 2002-02-21 17:00:27
|
Fixed on devCore ages ago, ported to RPI. > User: [#127] coke > MOO: 1.8.1+g1+s > Core: lily running rev 2.6.2 > Server Time: Tue May 15 15:39:16 2001 EDT > ---%report%---- > /permit phreaker rant author appears to ignore the "author" keyword. > This should be an error, I think. Several times over the past few weeks, > I've seen people use this command when they really meant to be using > /appoint, and the lack of an error message on the foobar'd usage > might be contributing to the problem. > ---%report%---- > > |
|
From: William J. C. <lil...@ce...> - 2002-02-21 16:29:29
|
Done. > User: [#3250] bartof > MOO: 1.8.1+g1+s > Core: lily running rev 2.6.2 > Server Time: Thu Oct 25 11:16:32 2001 EDT > ---%report%---- > Please add vodka to the list of drinks available through /drink there isn't > anything strong enough there > > ---%report%---- > > |
|
From: Josh W. <lil...@ce...> - 2001-11-13 01:57:27
|
Backported coke's fix for this bug to RPI core. |
|
From: William J. C. <lil...@ce...> - 2001-11-08 16:25:53
|
Fixed on devCore: -beener@devCore;?what > (devCore) (to beener) Coke asks, "what?" -beener@devCore;?what? > (devCore) (to beener) Coke asks, "what?" -beener@devCore;?what?? > (devCore) (to beener) Coke asks, "what??" Moving to the "for RPI" bucket so it will get copied to RPICore. > User: [#442] jeffro > MOO: 1.8.1+g1+s > Core: lily running rev 2.6.2 > Server Time: Thu Nov 8 11:10:31 2001 EST > ---%report%---- > it is common to type foo:?blah blah blah? > this results in there being 2 ?s at the end of the resulting send, > can the following logic be added to this code such that: > if there exists a ? at the end of the string it should be stripped off > > thank you > ---%report%---- > > |
5 messages has been excluded from this view by a project administrator.
