| # | User | Message | Date |
| 3163 | btiffin | Thanks Gabriele; I knew there was a more concise method of getting at time! from date arithmetic, but I got sidetracked when the google search wanted to show me COBOL data arithmetic. ;) Can't ever know enough COBOL, err, aaah, REBOL. | 25-Aug-09 16:25 |
| 3162 | Gabriele | (or difference now/precise then if necessary) | 25-Aug-09 9:59 |
| 3161 | Gabriele | btiffin, just use difference now then | 25-Aug-09 9:59 |
| 3160 | btiffin | re; wait till time, isn't that add multiply subtract then/date now/date 86400 subtract then/time now/time then - now * seconds per day + delta hours? Negative time! possible, which it seems wait takes as zero anyway. | 25-Aug-09 0:56 |
| 3159 | Gabriele | graham, the only solution to that would be to wait, say, 10 seconds at a time, and check. but it really depends on the application... | 24-Aug-09 8:23 |
| 3158 | PeterWood | you -> you're | 24-Aug-09 3:58 |
| 3157 | PeterWood | What happens if someone changes the machine's clock while you wating for a length of time ? | 24-Aug-09 3:58 |
| 3156 | Graham | what should? | 24-Aug-09 0:38 |
| 3155 | Graham | what happens if someone changes the clock while you're waiting on a date! ? | 24-Aug-09 0:38 |
| 3154 | Oldes | I agree, that it should be supported directly, so is there the ticket already? | 24-Aug-09 0:25 |
| 3153 | Gregg | An excellent solution, but you still can't wait on a date!. :-) | 23-Aug-09 23:38 |
| 3152 | Maxim | always someone to prove another wrong... ;-) | 23-Aug-09 0:22 |
| 3151 | Oldes | wait-date: func [date [date!]][wait difference date now] | 22-Aug-09 21:41 |
| 3150 | Gregg | You can't wait on date! AFAIK. | 21-Aug-09 13:49 |
| 3149 | Henrik | good idea. create a curecode wish for it, please. | 14-Aug-09 10:30 |
| 3148 | Pekr | would be good feature to have at least in R3 ... | 14-Aug-09 10:14 |
| 3147 | Dockimbel | Precisely, I'm working on a scheduler lib for UniServe and I was wondering if I could wait for date!, but it looks like not. | 14-Aug-09 9:45 |
| 3146 | Graham | Being able to wait for specified date/time would be great for doing cron | 14-Aug-09 9:27 |
| 3145 | Graham | It's probably a documentation issue. | 14-Aug-09 9:25 |
| 3144 | Graham | doesn't it mean a time value? | 14-Aug-09 9:24 |
| 3143 | Dockimbel | I've searched RAMBO about a WAIT inconsistency : the dictionnary says that "If the value is a DATE/TIME, wait until that DATE/TIME", but date! are not accepted as argument (both directly or in a block). If this a known bug? I can't find it in RAMBO. | 14-Aug-09 9:22 |
| 3142 | ? | I verified this same bug today http://www.rebol.net/cgi-bin/rambo.r?id=3357& The workaround is to use /binary and then the limit is gone. | 12-Jan-09 3:13 |
| 3141 | Gabriele | the main thing is, that changing rambo (i don't know the code) would take me more time (especially testing and making sure we're not going to lose data) than the 20 seconds or so it takes to delete the spam. So I never get to study the code and see what can be done... | 14-Oct-08 9:10 |
| 3140 | Gabriele | given that there is not much protection in rambo, it's probably bot spam. | 14-Oct-08 9:08 |
| 3139 | Graham | can you add a rebol captcha to it to save you work? | 14-Oct-08 8:58 |
| 3138 | Graham | is it all human spam? or bot spam? | 14-Oct-08 8:57 |
| 3137 | Gabriele | About the spam, I clean that up every single day. What you see is one day worth of spam. | 14-Oct-08 8:57 |
| 3136 | Gabriele | I think this might be in RAMBO already. At least I remember mentioning this problem to Carl a few years back. As Brian says, it's a missing /ALL refinement. | 14-Oct-08 8:57 |
| 3135 | BrianH | It sounds like the preprocessing is loading and molding the code before encapping, without using mold/all. | 13-Oct-08 16:25 |
| 3134 | Henrik | RAMBO is still used for R2 bugs, yes. | 13-Oct-08 15:04 |
| 3133 | Dockimbel | Should I RAMBO that ? Is RAMBO still used ? | 13-Oct-08 15:00 |
| 3132 | Dockimbel | rebview and enface are both 2.7.6.3.1 | 13-Oct-08 14:56 |
| 3131 | Dockimbel | enface => word! | 13-Oct-08 14:55 |
| 3130 | Dockimbel | rebview => none! (correct result) | 13-Oct-08 14:55 |
| 3129 | Dockimbel | REBOL [] probe type? first [#[none]] halt | 13-Oct-08 14:55 |
| 3128 | Dockimbel | I've just run in a bug in enface.exe (2.7.6.3.1). The following code doesn't give the same result if run under view or encapped with enface : | 13-Oct-08 14:55 |
| 3127 | Dockimbel | Looks like RAMBO needs to be cleaned from spam posts... | 13-Oct-08 14:53 |
| 3126 | Alan | . | 14-Sep-08 7:02 |
| 3125 | Gabriele | thanks. | 7-Apr-08 10:46 |
| 3124 | NormanDep | [ 4321 ] this is actualy a borderliner.. Im not sure this is default behavior in windows or not, liinux does not have this problem, could stay open.. | 6-Apr-08 21:19 |
| 3123 | NormanDep | yes sure... [ 4322 ] SDl 276 was recompiled for both kernel 2.4 and kernel 2.6 [DEBIAN] (previously only kernel 2.6 was compiled) and they worked here. I cant confirm on ubuntu as its not my flavor of yoghurt ;-) | 6-Apr-08 21:16 |
| 3122 | Gabriele | Norman, could you please elaborate? It might help people noticing the same thing. | 6-Apr-08 8:24 |
| 3121 | NormanDep | [ 4321 ] can be closed | 5-Apr-08 21:08 |
| 3120 | NormanDep | [ 4322 ] can be closed | 5-Apr-08 21:07 |
| 3119 | btiffin | Do we still bother reporting to RAMBO? Is there any expecations for a production 2.7.6? I'd vote; please please please. | 21-Sep-07 1:27 |
| 3118 | Gabriele | yes, but semantically a/:b/c is a/(b)/c not a/(b/c) which is what you want. | 17-Jul-07 5:41 |
| 3117 | Dockimbel | btw, a/(:b/c) is quite heavy => 3 series instead of 1. | 16-Jul-07 12:22 |
| 3116 | Dockimbel | Great! I've forgot paren! evaluation in paths. | 16-Jul-07 12:19 |
| 3115 | Henrik | >> a: %path == %path >> b: context [c: %target] >> a/:b/c == %path/c:%20%target%0A/c >> a/(:b/c) == %path/target | 16-Jul-07 11:45 |
| 3114 | Henrik | slipping objects into a path... | 16-Jul-07 11:40 |
| 3113 | Dockimbel | Yes, it returns the object source and the point is is this useful to anyone ? I was hoping the behaviour of :b in a path! could be changed to something more useful, like acting as a pass-thru to /c, so that, in the ticket example, a/:b/c would results in %path/target. | 16-Jul-07 11:32 |
| 3112 | Henrik | or perhaps form | 16-Jul-07 9:14 |
| 3111 | Henrik | DocKimbel, #4288 looks to me like it inserts a molded object into the path. | 16-Jul-07 9:00 |
| 3110 | Sunanda | Re my trim question of a week or so ago.... Thanks for the responses. From RAMBO it seems this is deliberate (if unexpected) behavior: http://www.rebol.net/cgi-bin/rambo.r?id=3681 "This is intentional and not a bug. TRIM was designed that way to work well for trimming LINES of text. " [my emphasis of lineS, plural] | 12-Jul-07 19:00 |
| 3109 | Dockimbel | RAMBO lacks a free commenting support... | 12-Jul-07 18:41 |
| 3108 | Henrik | then it's probably been forgotten in Gabriele's priority list for 2.7.6. | 12-Jul-07 18:41 |
| 3107 | Dockimbel | I think that it's already in RAMBO | 12-Jul-07 18:40 |
| 3106 | Henrik | wouldn't hurt :-) | 12-Jul-07 18:34 |
| 3105 | Pekr | "On windows platforms, you'll get the infamous DOS window flashing when executing an external CGI ! It's just a matter of 1 flag to correctly set in 'call C source code, if you're really annoyed by that, ask RT to fix it asap (for 2.7.6 that would be good)! ;-) I may reimplement completely call command in REBOL, but it would be a big waste of time and energy...it should be a 10 minutes fix for RT. Addind a time limit to 'call would be a good thing too, it would also avoid me the reimplementation of 'call to add such feature...." - DocKimbel Anx chance of getting above fixed? Should we rambo it? | 12-Jul-07 18:33 |
| 3104 | Anton | Sunanda, I think, from memory of old conversation, that the default TRIM behaviour is particular and just insufficiently documented. It's annoying, chuck it in RAMBO to specify exact behaviour in doc string. | 6-Jul-07 11:42 |
| 3103 | Izkata | Hence why I always use trim/head/tail... I didn't think it was a bug, though, since your first example - trim " a ^/ ^/ a " - could be a shortcut for data files.. Trimming each line. | 4-Jul-07 18:01 |
| 3102 | Sunanda | I'm beginning to think so too, especially as (from my reading of the function), these two should be equivalent trim/head/trail " a ^/ ^/ a " trim" a ^/ ^/ a " | 3-Jul-07 14:52 |
| 3101 | Rebolek | TRIM behaviour is strange. Sometimes it removes too much as in your case, sometimes it removes too little as in (trim "^/a^/" == "a^/") . I would say it's a bug. | 3-Jul-07 12:45 |
| 3100 | Sunanda | Is rhis a bug, or just undocumented behavior? trim " a ^/ ^/ a " == "a^/^/a" The help says "Removes whitespace from a string. Default removes from head and tail." But in this case it seems to treat the string as a set of strings (separated by newline) and trims them all. Compare with the expected behavior here: trim " a b a " == "a b a" | 3-Jul-07 12:22 |
| 3099 | Dockimbel | 2.6.2 and 2.7.5, Windows and Linux (probably others too) : Encmd crashes if 'title keyword is used in 'encap header. It works correctly with enpro and enface. | 2-Jul-07 21:51 |
| 3098 | Gabriele | if it has been deleted, there's no way to recover it. | 1-Jul-07 15:39 |
| 3097 | Graham | No .. did you want me to ?? | 1-Jul-07 9:09 |
| 3096 | Gabriele | did you re-enter it? | 1-Jul-07 6:54 |
| 3095 | Graham | yeah ... I think you nuked it :( | 30-Jun-07 12:27 |
| 3094 | Gabriele | i haven't seen it. worst case it was deleted with the spam (i check them carefully, but i may have missed it) | 30-Jun-07 12:09 |
| 3093 | Graham | what happened to my https rambo report ?? :( | 30-Jun-07 10:52 |
| 3092 | Steeve | yeah , it's the normal behaviour for to block! , use load instead for binding | 30-Jun-07 4:04 |
| 3091 | Anton | Good one. | 30-Jun-07 3:43 |
| 3090 | Volker | to block! does not bind. word is not included in system/words. sometimes that results in an error-mesage and sometimes in a crash. | 29-Jun-07 23:56 |
| 3089 | btiffin | reported. | 29-Jun-07 22:59 |
| 3088 | Tomc | windows REBOL/View 1.3.2.3.1 5-Dec-2005 Core 2.6.3 goes boom | 29-Jun-07 22:54 |
| 3087 | btiffin | get first to block! {'thing} returns an error message ** Script Error: thing word has no context b: first to block! {'thing} == 'thing get b segfaults. | 29-Jun-07 22:53 |
| 3086 | Frank | Got the same result... 1.3.2.4.2 and 2.7.5.4.2 | 29-Jun-07 22:52 |
| 3085 | btiffin | How about this on your end...just trying to reduce the code for the RAMBO report. foreach a to block! {'word} [print get a] - this segfaults on Linux. too. | 29-Jun-07 22:43 |
| 3084 | btiffin | I'll check RAMBO add if not in there then...thanks Graham...I just reduced it to this so far...more experimenting to come. | 29-Jun-07 22:30 |
| 3083 | Graham | is it recursive? | 29-Jun-07 22:29 |
| 3082 | Frank | +1 1.3.2.4.2 and 2.7.5.4.2 Linux | 29-Jun-07 22:29 |
| 3081 | Graham | crashes windows as well | 29-Jun-07 22:28 |
| 3080 | btiffin | yep | 29-Jun-07 22:28 |
| 3079 | Graham | linux version | 29-Jun-07 22:25 |
| 3078 | btiffin | Can I get someone to try this before I report it. foreach [e s] to block! {thing 'word} [compose [e (get s)]] segfaults 1.3.2.4.2 and 2.7.5.4.2 | 29-Jun-07 22:18 |
| 3077 | Graham | rambo'd https posting bug. | 28-Jun-07 20:19 |
| 3076 | Anton | To maybe fit in better with other styles, the caret colour can be changed. eg: area with [append init [named-colours: make named-colours [caret: black]]] | 20-Jun-07 10:09 |
| 3075 | Anton | Cool, let me know any problems. | 20-Jun-07 10:02 |
| 3074 | PeterD | Thanks Anton | 20-Jun-07 10:00 |
| 3073 | Anton | (oh well, I guess it's one big bug workaround) | 19-Jun-07 16:30 |
| 3072 | Anton | I should have announced that in the View group, sorry. | 19-Jun-07 16:29 |
| 3071 | Anton | Advantages: - middle and right aligned text is now usable and works as one would expect, with the caret appearing in the correct position. - you can render the caret how you like - you can render the highlighting how you like (I didn't show the above options clearly in the demos yet, you must still get your programming fingers dirty) Disadvantages: - lots of code to achieve the above - probably slow performance with large areas, because images are being created on every redraw | 19-Jun-07 16:27 |
| 3070 | Anton | First run View 2.7.5.3.1 and do this: site: select load-thru http://www.rebol.net/reb/index.r [folder "Anton"] clear find site %index.r load-thru/update site/patch/caret-to-offset-patch.r Do the main demo, showing patched AREA: do-thru site/patch/demo-caret-to-offset-patch.r Three patched styles; AREA, FIELD, INFO: do-thru site/gui/demo-area.r do-thru site/gui/demo-field.r do-thru site/gui/demo-info.r The initial experimental testing script: do-thru site/patch/test-caret-to-offset-patch.r | 19-Jun-07 16:18 |
| 3069 | Anton | I've finally done it. Here is an AREA/FIELD style which handles and renders the caret much better with center and right-aligned text: | 19-Jun-07 16:18 |
| 3068 | btiffin | Chris; Umm, not according to help any. It returns the first value that is not false or none. So I guess unset! counts. :) But you're right. unset! should be more false than true. | 17-Jun-07 7:32 |
| 3067 | Chris | any [get/any 'no-word "Alt"] ; should this return "Alt" ? | 17-Jun-07 2:10 |
| 3066 | Oldes | never mind, you can delete it, I already have a solution... anyway... it would be nice to replace the clean-path function with the Anton's simple-clean-path | 13-Jun-07 14:52 |
| 3065 | Oldes | so it's bug here: >> make-dir/deep %aaa//bb/ ** Access Error: Cannot open aaa// ** Near: make-dir/deep %aaa//bb/ | 13-Jun-07 14:50 |
| 3064 | Gabriele | REBOL does not ignore multiple slashes. However, this is not documented anywhere, so I'm not sure what the rules should be. | 13-Jun-07 6:12 |
| 3063 | Gabriele | >> what-dir == %/home/giesse/ >> read %/ == [%proc/ %initrd/ %sys/ %bin/ %initrd.img %media/ %Recycled/ %srv/ %usr/ %etc/ %boot/ %vmlinuz %lib/ %mnt/ %tmp/ %sbin/ %cdrom/ %... >> read %// == [%.directory %giesse/] >> read %/// == [%Detective/ %.hplip.conf %.teamspeak2/ %.mythtv/ %.qt/ %.fontconfig/ %.clay/ %.Skype/ %.recently-used %.face.icon %.DCOPserver_... | 13-Jun-07 6:12 |
| 3062 | Gabriele | notice this behavior: | 13-Jun-07 6:12 |
| 3061 | Gabriele | Oldes, regarding your multiple slashes ticket... | 13-Jun-07 6:12 |
| 3060 | Anton | Also note, to get the caret and highlight handling / rendering working properly will require you to do in Rebgui the equivalent of the above ctx-text patching etc. That's quite a bit of work. | 12-Jun-07 12:36 |
| 3059 | Anton | Here's what I have so far. (Note, this code may end up in another file.) http://anton.wildit.net.au/rebol/patch/caret-to-offset-patch.r | 12-Jun-07 12:29 |
| 3058 | Ashley | Could you post/email me just the caret-to-offset and offset-to-caret patches? That should be enough for me to get RebGUI working. Thanks. | 12-Jun-07 12:19 |
| 3057 | Anton | I was disappointed to find that merely patching caret-to-offset and offset-to-caret was not enough to fix the highlight and caret rendering. The View system does not appear to use them. (Maybe the View system keeps direct references to the native functions and does not refer to these global words to get to the native functions ?) This means that ctx-text and focus/unfocus have to be patched to prevent system/view/caret and highlight-start/end being set and thus rendering the highlight and caret. | 12-Jun-07 12:05 |
| 3056 | Anton | Ashley, the patching is quite heavy; - caret-to-offset and offset-to-caret replaced by mezzanines (mainly dependent on the TEXTINFO native) - in ctx-text, patched 10 functions and 2 feel objects (should be backwards compatible) - replaced the View rendering of the highlight and caret using several intermediate images (which will be slow for large faces) | 12-Jun-07 11:49 |
| 3055 | BrianH | The "Invalid argument: none" is just the default value of the second parameter that never gets used if you don't specify /part. | 11-Jun-07 4:57 |
| 3054 | BrianH | The /part is necessary when removing from a bitset, | 11-Jun-07 4:52 |
| 3053 | BrianH | Try this: remove/part charset "abc" "a" | 11-Jun-07 4:51 |
| 3052 | Oldes | yes.. that's what I forgot... but anyway... removing ? char is not enough:( | 10-Jun-07 22:32 |
| 3051 | Sunanda | Charsets don't always respond the way you'd expect -- or support all the operators they could. One way to remove a char: use difference: >> (charset "ac") = (difference charset "abc" charset "b") == true | 10-Jun-07 22:20 |
| 3050 | Oldes | why this is not working? >> remove charset "abc" "a" ** Script Error: Invalid argument: none ** Near: remove charset "abc" "a" when in doc is: Character sets can also be modified with the insert and remove functions, or combinations of sets can be created with the union and intersect functions. | 10-Jun-07 22:12 |
| 3049 | Oldes | Is it so difficult to remove a char from charset or I forgot something? | 10-Jun-07 22:07 |
| 3048 | Oldes | the bug is in the URL-parser of course... there should not be ? char in path-chars | 10-Jun-07 21:46 |
| 3047 | Oldes | There is a bug in decode-url:
>> probe decode-url http://test/path/target?text/something
make object! [
user: none
pass: none
host: "test"
port-id: none
path: "path/target?text/"
target: "something"
] the target should be: target?text/something | 10-Jun-07 21:41 |
| 3046 | Ashley | Good news, does it involve patching caret-to-offset and/or offset-to-caret (via mezz wrappers)? | 6-Jun-07 12:47 |
| 3045 | Anton | (and vertical alignment too !) | 6-Jun-07 8:40 |
| 3044 | Anton | It is with pleasure that I can announce that there is a workaround to the center / right aligned text highlighting issue. I have a working prototype. You can change the horizontal alignment of the face on the fly. Give me a day or two to clean it up and make a nice demo. | 6-Jun-07 8:39 |
| 3043 | Anton | Doc, ah yes, I think I agree because I seem to remember doing the above sequence myself at some time. | 6-Jun-07 8:35 |
| 3042 | Dockimbel | Anton: yes, Windows | 4-Jun-07 17:37 |
| 3041 | Dockimbel | specs: info? a-file
if specs/type = 'file [
probe read a-file
] ** Access Error: Cannot open /C/Dev/REBOL/script.r/ ** Near: read a-file | 4-Jun-07 17:36 |
| 3040 | Dockimbel | In my example above, the file! value is explicit, but in cases where it's not, it produces an odd and illogical bug, IMHO. See this other example : | 4-Jun-07 17:36 |
| 3039 | Dockimbel | The issue I wanted to point out is just that if it's an existing file!, I should be able to read it ! So instead of letting the user wrongly think that's a file, and let 'read pop an error (which sounds illogical to me), I'm proposition to signal in 'info? that something is wrong with that file! value. | 4-Jun-07 17:33 |
| 3038 | btiffin | Well I don't think it's weird anymore. make port! on %file/ uses scheme: 'directory make port! on %file uses scheme: 'file | 1-Jun-07 3:21 |
| 3037 | btiffin | I get the DocKimbel behaviour with 2.7.5.4.2 Linux. But I see the point. Something weird in query...or make port! on files disguised as dir specs... | 1-Jun-07 3:10 |
| 3036 | Anton | If it's Windows, then I expect internally rebol just does this:
>> to-local-file %user.r/
== "user.r" stripping the final slash before accessing the file-system. | 1-Jun-07 3:05 |
| 3035 | btiffin | Umm is it the trailing slash? | 1-Jun-07 3:05 |
| 3034 | Anton | Yes, probably. Which platform are you on ? | 1-Jun-07 3:03 |
| 3033 | Dockimbel | >> probe info? %script.r/
make object! [
size: 3405
date: 12-Sep-2000/21:40:20+2:00
type: 'file
] >> read %script.r/ ** Access Error: Cannot open /C/Dev/REBOL/script.r/ ** Near: read %script.r/ Shoudn't INFO? return none (or an error) in this case ? | 30-May-07 20:44 |
| 3032 | Volker | + platform + swing-widgets. But did not try yet. | 30-May-07 10:37 |
| 3031 | Volker | If incremental dependency-based evaluation is what i think it is they may have an edge. | 30-May-07 10:36 |
| 3030 | Pekr | Full REBOL instead of their partial FX? :-) | 30-May-07 10:32 |
| 3029 | Volker | Or sun. They promote half of the syntax currently. | 30-May-07 10:30 |
| 3028 | Volker | WOuld mean Carl never gets at apple. Maybe google. :) | 30-May-07 10:30 |
| 3027 | Volker | Wrong smiley :( | 30-May-07 10:29 |
| 3026 | Pekr | or some big announcement - e.g. MS buying RT on that date :-) | 30-May-07 10:28 |
| 3025 | Pekr | some mystical one, for e.g :-) | 30-May-07 10:27 |
| 3024 | Volker | "ie before july 15th r3 ***release***" :) | 30-May-07 10:27 |
| 3023 | ? | What more meaning does it need than that Carl said he would do it? | 30-May-07 10:27 |
| 3022 | Pekr | Gabriele - what's behind the date? :-) It is just that Carl decide to release R3 at that particular date, or has it any other internal meaning? :-) | 30-May-07 6:51 |
| 3021 | Gabriele | note, i didn't say "won't be fixed", i said that i find it unlikely that Carl will spend more time on 2.7 at this time (ie before july 15th r3 release). | 30-May-07 6:46 |
| 3020 | PeterD | Great way of "masking" the problem, I love it! | 30-May-07 0:43 |
| 3019 | PeterD | Volker, Thanks that saves a few, indeed. My frustation is that we have to be to "REBOLish", a text box is as simple as it gets (maybe excluding a label), one can not be forced to adapt to the bugs and "adapt" to a new enforced way of editing text !!! | 30-May-07 0:42 |
| 3018 | Volker | ;Not perfect, but less clicky view layout [ style cfield field center feel [ redraw: func [face act pos] bind [ if all [in face 'colors block? face/colors] [ face/color: pick face/colors face <> focal-face ] foc?: same? face system/view/focal-face face/font/align: either foc? ['left] ['center] ] system/view ] cfield "hello" with [focus self] cfield "cflied2" cfield "cfield3" ] | 29-May-07 22:45 |
| 3017 | Graham | Known for ages and won't be fixed .... :( | 29-May-07 21:54 |
| 3016 | PeterD | Forgot to include Gabriele's response. The short form is Yes, known for ages No will not be fixed (in 2.7 there is) Yes the glorious R3 will (probably) fix it | 29-May-07 21:38 |
| 3015 | PeterD | Dear Anton, A mezzanine, that's it. I can not tell you how frustrated I am. See my response to Gabriele below: Thanks for the info. It is so sad to see that "little" things are not fixed in a reasonable fashion. Here I am, 99% of my stuff is Center aligned and I find myself "regretting" that I go for a "not so established" language. (never thought that entering text in a box will be a problem) I have to actually ask 1000 people to klick 4 times more often, just to overcome a stupid bug. So I ask them to: Change to left align Edit Go back to Center align Repeat as long as needed and pardon, I used "REBOL" Best regards So, what is needed to fix this, please let's include Ashley Thanks a ton for the shimmer of light I see at the end of the tunnel Peter | 29-May-07 21:31 |
| 3014 | Anton | You meant, center and *right* aligned text can not be edited. But yes, this is a long-standing bug, and it's annoyed me a few times. Actually, this is something that *could* be worked around. We just need to figure out how caret-to-offset and offset-to-caret work, then write mezzanines to replace them. I've been meaning to do this for a while. | 29-May-07 11:33 |
| 3013 | Will | Have to agree with Pekr about naming issues!! Let find something sexier that anyone would be attracted to 8-). | 29-May-07 11:32 |
| 3012 | PeterD | Gabriele,
Can you please take a look at these 2 submissions: http://www.rebol.net/cgi-bin/rambo.r?id=4274& http://www.rebol.net/cgi-bin/rambo.r?id=4161& I am desperate because center and left aligned text can not be edited. Ca you please help? I convinced myself and 2 others to go REBOL with a small but important app I need, but simple stuff like this kills the idea. | 29-May-07 10:53 |
| 3011 | Pekr | Gabriele - you talk about two distinctive things, but we shold probably move from this group. | 25-May-07 6:53 |
| 3010 | Pekr | btiffin - only if group takes some sensible name :-) all those RUGs etc. remind me of linux or amiga groups, noone can depict the acronym and it sounds ugly, actually nothing I would like to wear on my T-shirt :-) | 25-May-07 6:53 |
| 3009 | Gabriele | r3 will be open enough that people will be able to work on it without Carl's intervention. but for things that require Carl's intervention we follow Carl's rules. | 25-May-07 6:51 |
| 3008 | Gabriele | petr, remember the open view 1.3 project? the problem it didn't get anywhere (despite producing a lot of good code) is that Carl does not work that way. we can only aknowledge it. | 25-May-07 6:50 |
| 3007 | btiffin | All right. Two Brians...We win. But Pekr; RT has to be careful with this. Giving it out to too many will just generate too much noise... I'd gladly take my name off the list and wait, as to not overwhelm those in more appropriate positions...I'd rather get handed Government Reject Unfit for Normal Training work. Not that it isn't a nice shiny carrot dangling ever so close to the nose. And, being a little schizoid, I also agree with you. I surely hope you allow us to nominate you for Secretary of the (proposed) REBOL User Group. The (proposed) Executive Summary could definitely use your candor. :) | 25-May-07 6:46 |
| 3006 | Pekr | IIRC, there should be VID+ group, which was supposed to discuss what direction new VID should go. There is many talented ppl with various povs here, who could influence some decision in a good way imo ... | 25-May-07 6:18 |
| 3005 | Pekr | we are going thru the same attitude over and over again, for many years. First RT blogs, asks, debates, then closes the door and comes up with something,not asking if we like it or not ... then complaining, that we complain ;-) | 25-May-07 6:17 |
| 3004 | Pekr | hmm, well, I can wait till late release. But - I don't like the attitude already - "like adding people when i have some vid stuff to show" ... that simply sucks | 25-May-07 6:16 |
| 3003 | Pekr | ah, wait, I forgot myself :-) | 25-May-07 6:15 |
| 3002 | Pekr | sorry if I forgot someone :-) | 25-May-07 6:15 |
| 3001 | Pekr | R3 list initial release - BrianH, Anton, Volker, Henrik, Ashley, Graham, Gregg, Dockimbel, Sunanda, btiffin ... simply ppl who are skilled, and/or actively use Rebol with own projects ... | 25-May-07 6:15 |
| 3000 | Graham | :) | 25-May-07 5:47 |
| 2999 | Graham | Shall I create a R3 list here then ? :( | 25-May-07 5:46 |
| 2998 | Gabriele | i actually want to try that out before july... but not sure i'll have the time. | 25-May-07 5:44 |
| 2997 | Graham | So, is chord ready for R3 ? :) | 25-May-07 5:42 |
| 2996 | Gabriele | (personally i want it to be dynamic. like adding people when i have some vid stuff to show.) | 25-May-07 5:41 |
| 2995 | Graham | Ahh.. the Carl bottleneck problem. | 25-May-07 5:41 |
| 2994 | Gabriele | i don't think there's a fixed list that has been written yet. | 25-May-07 5:40 |
| 2993 | Gabriele | next bug fix - no idea. depends on Carl's time. | 25-May-07 5:40 |
| 2992 | Graham | who gets to see R3 on the first of Jun ? | 25-May-07 5:40 |
| 2991 | Gabriele | dir req.......... R3. | 25-May-07 5:39 |
| 2990 | Graham | when is the next bug fix cycle? | 25-May-07 5:39 |
| 2989 | Gabriele | maybe we should follow reichart's bug fixing rules... but i can't redo the list ten times... | 25-May-07 5:39 |
| 2988 | Graham | system ... | 25-May-07 5:39 |
| 2987 | Graham | Why can't we get a directory requestor? | 25-May-07 5:38 |
| 2986 | Graham | oh :( | 25-May-07 5:38 |
| 2985 | Gabriele | because the ticket was created much after the list for 2.7.6 was created :-) | 25-May-07 5:38 |
| 2984 | Graham | why couldn't 4275 be fixed? Should be easy enough! | 25-May-07 5:35 |
| 2983 | Gabriele | anyway - you're right, but even though the target face may never be reached, if it is known already it would be good to have it there for many reasons. | 25-May-07 5:30 |
| 2982 | Gabriele | i think there was a reason for it being critical... hmm. | 25-May-07 5:29 |
| 2981 | Anton | And I think the Importance should be lowered from Critical. | 25-May-07 4:42 |
| 2980 | Anton | Gabriele, could you please add this note to #3867: "Update: I now understand that the events trickle down in a dynamic fashion and it cannot be known (for certain) at the beginning whether an event will arrive at a particular face, as DETECT functions along the way to the face can alter the route. -Anton" | 25-May-07 4:42 |
| 2979 | Gabriele | Oldes, unless the OS is really broken there is no need to release memory, because unused memory just gets paged out. | 24-May-07 17:19 |
| 2978 | Henrik | I just think there should be better clarity on what are do's and don'ts in terms of how to preserve memory and have a stable application at the same time. Some apps of mine never eat more than 3-5 MB RAM, while others eat 250 MB RAM, and I don't know what causes it. | 24-May-07 14:25 |
| 2977 | Oldes | never? maybe it would be good to have some way how to force rebol to release what does not require from time-to-time. That's probably the reason why my nonstop running server requires 5MB instead of 3MB when was started. | 24-May-07 14:23 |
| 2976 | Henrik | Thanks for the explanation | 24-May-07 9:30 |
| 2975 | Gabriele | recycle never releases memory to the system (afaik) because that's usually inefficient, better to keep it for future usage. | 24-May-07 6:54 |
| 2974 | Gabriele | henrik, with recycle/off, no memory is ever reused, and obviously rebol is constantly allocating memory for temporary values and so on. so used memory grows. when you do a recycle, the gc will collect all the garbage and start reusing it for later allocations, so that memory used stops to grow until you get to the same point as before and rebol needs more memory. | 24-May-07 6:53 |
| 2973 | Henrik | a: [ append a [+ 1] 1] loop 1000 [ print [ do a newline ] print [ "Block length: " length? a "Bytes used: " ((length? a) * 16) ] ] | 24-May-07 4:52 |
| 2972 | Henrik | http://www.rebol.org/cgi-bin/cgiwrap/rebol/ml-display-message.r?m=rmlPSTK <--- I can't find this old bug in RAMBO, and it still crashes REBOL. | 24-May-07 4:50 |
| 2971 | Henrik | I must point out that recycle specifically was turned off and so the number would just keep growing for hours eating up 100s of MB. Recycle is probably normally invoked, if you don't specify that it has to be turned off. The fact that the memory usage just keeps growing in an idle situation seems just like a memory leak to me. | 24-May-07 4:42 |
| 2970 | Gregg | I don't know, but I've seen similar allocations that continue over time and then seem to stop. | 24-May-07 4:22 |
| 2969 | Henrik | I'm studying memory usage and recycle for a bit. Whenever I'm adding a block or doing an operation, REBOL might consume small chunks of memory continuously, like 16-32 kb per second. whenever recycle is applied, it just stops. Why is that? | 23-May-07 23:02 |
| 2968 | Anton | Same with paren! | 22-May-07 15:18 |
| 2967 | Anton | This is interesting because a path is a series, supposedly very similar to a block. | 22-May-07 15:16 |
| 2966 | Anton | Copy/part can't use a path! as its RANGE argument >> path: 'svvc/color == svvc/color >> copy/part path back tail path ** Script Error: Invalid /part count: color ** Near: copy/part path back tail path | 22-May-07 15:15 |
| 2965 | Gabriele | lol - Carl does submit tickets too. it's just to remember about the bugs we find. | 22-May-07 12:06 |
| 2964 | Pekr | or pathological :-) | 22-May-07 10:37 |
| 2963 | Pekr | Graham - actually it might be educative :-) | 22-May-07 10:37 |
| 2962 | Graham | Gab .. are you submitting and then replying to your own tickets? | 22-May-07 9:46 |
| 2961 | Anton | Excellent, that's what I wanted to know, thankyou. | 21-May-07 11:00 |
| 2960 | Oldes | Note: Many pre-HTTP/1.1 user agents do not understand the 303 status. When interoperability with such clients is a concern, the 302 status code may be used instead, since most user agents react to a 302 response as described here for 303. | 21-May-07 10:59 |
| 2959 | Oldes | http://tools.ietf.org/html/rfc2616#section-10.3.4 | 21-May-07 10:59 |
| 2958 | Oldes | official HTTP1.0 spec doesn't know 303 response. And there are also missing 305 and 307 forward responses. | 21-May-07 10:58 |
| 2957 | Anton | Ok, so let me restate the situation: Due to a buggy foreign server, we are patching our HTTP scheme, which declares itself as HTTP1.0, with a part from HTTP1.1. (I just want to clarify that HTTP 1.0 does not contain 303.) | 21-May-07 10:58 |
| 2956 | Oldes | it's patch for buggy foreign servers... as server should not return HTTP1.1 response if client requires HTTP1.0 | 21-May-07 10:53 |
| 2955 | Anton | (if not, then this should be called a "workaround patch" or "temporary migration patch") | 21-May-07 7:24 |
| 2954 | Anton | Oldes, how do you classify this patch ? Is it simply improving Rebol's HTTP 1.0 scheme, or is it half-way sliding towards HTTP 1.1 ? (ie. does the official HTTP 1.0 spec contain a 303 response ?) | 21-May-07 7:20 |
| 2953 | Anton | Oldes, note that you can do this, which looks clearer to me: select second get in system/schemes/http/handler 'open [response-actions:] | 21-May-07 7:13 |
| 2952 | Oldes | there is a silly bug in my patch, it should be: use [tmp][ tmp: select second get in system/schemes/http/handler 'open to-set-word 'response-actions if none? find tmp 303 [ insert tmp reduce [303 select tmp 302] ] ] | 19-May-07 22:35 |
| 2951 | Oldes | it should be easy imho | 19-May-07 22:29 |
| 2950 | Oldes | (Reichard: will be fixed the Altme bug which cripples text with long links?) | 19-May-07 22:29 |
| 2949 | Oldes | whith the patch above you should be able to do for example: trace/net on p: open/direct http://www.youtube.com/get_video?video_id=FVbf9tOGwno&t=OEgsToPDskKR0Ng6kANs3Z4VNG81T2tZ error? try [close p] | 19-May-07 22:27 |
| 2948 | Oldes | just found, that youtube do not respect HTTP1.0 protocol => sends HTTP1.1 303 response even if client require HTTP1.0 (which is Rebol case). As there is no response specified for 303 in Rebol's http handler, it can be fixed using: use [tmp][ tmp: select second get in system/schemes/http/handler 'open to-set-word 'response-actions if none? find tmp 303 insert tmp reduce [303 select tmp 302] ] | 19-May-07 22:22 |
| 2947 | Henrik | something that randomly creates a large amount of blocks, inserts, deletes, manipulates, copies and does various other things. | 19-May-07 17:48 |
| 2946 | Gabriele | but i guess it won't show in that case... | 19-May-07 17:42 |
| 2945 | Gabriele | recycle/torture | 19-May-07 17:42 |
| 2944 | Henrik | well, if it's about memory allocation and clean up, would there not be a way to torture it? What's the worst possible way to stress the garbage collector? | 19-May-07 17:35 |
| 2943 | Gabriele | but at this point (focused on R3) RT does not have enough resources to debug a big app. | 19-May-07 17:23 |
| 2942 | Gabriele | i feel the pain - same problem i had with chord. | 19-May-07 17:23 |
| 2941 | Sunanda | I don't have anything trivial that will trigger the bug. It's a big application that can run for a while before crashing....And the code has been tweaked to minimise the occurrence of the problem. | 19-May-07 17:18 |
| 2940 | Gabriele | anyone willing to find a way to reproduce it? | 19-May-07 17:17 |
| 2939 | Sunanda | Henrik, I see regular "Crash Should not happen" on one of my scripts, so you are not alone. | 19-May-07 15:58 |
| 2938 | Graham | Done. | 18-May-07 7:49 |
| 2937 | Henrik | it's not a problem the other way around, so yes, it's inconsistent. | 18-May-07 7:45 |
| 2936 | Graham | Ok | 18-May-07 7:44 |
| 2935 | Henrik | yep | 18-May-07 7:44 |
| 2934 | Graham | Rambo it ?? | 18-May-07 7:43 |
| 2933 | Henrik | confirmed under OSX | 18-May-07 7:24 |
| 2932 | Graham | this is an annoyance ... but 'to-local-file drops the trailing slash for directories | 18-May-07 5:13 |
| 2931 | Henrik | it's quite simple, I think it was based on some cookbook code. moving to ports for that... | 17-May-07 16:48 |
| 2930 | Henrik | actually I'm going to look at a printerserver, which deadlocks, if two people are trying to print too close to eachother. | 17-May-07 16:46 |
| 2929 | Sunanda | Good news! So you have a few days to fix the recycle problem for real :-) | 17-May-07 16:45 |
| 2928 | Henrik | ok, it ran perfectly. the demo was approved and the product goes live on Wednesday. | 17-May-07 16:42 |
| 2927 | Henrik | it will not run more than 2-3 hours today :-) | 17-May-07 13:41 |
| 2926 | Oldes | just make sure you recycle sometimes... if it's long running process | 17-May-07 13:26 |
| 2925 | Henrik | with recycle forced off, it seems to be running OK for now | 17-May-07 12:43 |
| 2924 | Volker | Its only for demo, and 3:30 left. better waste memory than a contract.. | 17-May-07 10:30 |
| 2923 | Oldes | allocating 100000 elements for each block will slow down performance too much I guess | 17-May-07 10:27 |
| 2922 | Oldes | anyway.... using make block! [] is quite useless | 17-May-07 10:23 |
| 2921 | Volker | ;like if 20 * 1000 * 1000 + stats > last-mem [ recycle . last-mem: stats ] ;and that every 0.01 second or so. | 17-May-07 10:23 |
| 2920 | Oldes | :) | 17-May-07 10:21 |
| 2919 | Oldes | you may try recycle/off and do it yourself | 17-May-07 10:21 |
| 2918 | Volker | i had such a problem with massive gui and async. Workarounded the following way: recycle is off permanently. there is a thread (do-every or such) which checks how much memory was allocated and when it is to much it recycled. crashing stopped. | 17-May-07 10:21 |
| 2917 | Henrik | I think I'll panic and allocate 100000 elements to every single block in the database | 17-May-07 10:03 |
| 2916 | Henrik | it crashed again :-( | 17-May-07 10:02 |
| 2915 | Sunanda | Let's hope that gets you through the demo....Good luck! | 17-May-07 9:42 |
| 2914 | Henrik | allocated 100000 to the first block in the code and it's still running... | 17-May-07 9:40 |
| 2913 | Sunanda | Clear -- It's probably a good idea for this reason: the block will grow to its maximum size after repeated uses, and so saves time in memory allocation / block extension. May be a bad idea if that max size is causing problems :-) | 17-May-07 9:29 |
| 2912 | Henrik | I had adopted the techinque of clearing a block before reusage instead of using a new make block! [] Maybe that's a bad idea. | 17-May-07 9:23 |
| 2911 | Henrik | sunanda, repeated clears of a block perhaps? | 17-May-07 9:22 |
| 2910 | Henrik | http://rebol.hmkdesign.dk/db-sync.r <-- the db sync code is here. | 17-May-07 9:20 |
| 2909 | Sunanda | To tell the truth, I don't know what I did with previous versions that actually worked. But doing *something* that affected garbage colection seemd to move the bug around. eg -- global words not local words -- xx: make block! 1000 not xx: copy [] | 17-May-07 9:18 |
| 2908 | Henrik | it seems to be accumulative, since it does not happen in exactly the same spot every tine and is possibly related to Rugby's do-every function, because it seems to happen whenever the do-every is executed. | 17-May-07 9:17 |
| 2907 | Henrik | the thing is that its db synchronization code (I'll think out loud here) and it's used in 5-6 different places. only in one place does it crash. | 17-May-07 9:15 |
| 2906 | Oldes | I think it would be good to have an example with this bug for sending it to Carl | 17-May-07 9:14 |
| 2905 | Henrik | it's actually a showstopper for me and exactly this code needs to be working in front of a customer in about 5 hours.... | 17-May-07 9:14 |
| 2904 | Sunanda | It's annoying! Sometimes just moving code around can fix it. Try making some local words global, for example. | 17-May-07 9:13 |
| 2903 | Henrik | I see. Unfortunately it seems I hit it close to every time I do a specific operation, but I have no time to debug it... | 17-May-07 9:09 |
| 2902 | Sunanda | Not gone entirely, but happens far less frequenty. Which makes it hard to debug. Very deeply nested blocks with many inserts and removes can trigger it. | 17-May-07 9:09 |
| 2901 | Henrik | this is on View 1.3.2 | 17-May-07 9:07 |
| 2900 | Henrik | I'm hitting something that causes "invalid datatype during recycle" sometimes. I don't know yet what it is, but I thought the recycle bug was gone? | 17-May-07 9:04 |
| 2899 | Anton | :-) I don't know. I kept notes in a file, but don't feel it's developed enough to publish. I have a vague desire for a new function which handles this case (as well as other, more general, set operations). | 12-May-07 15:55 |
| 2898 | Gregg | It would be a good guru tech-note to post somewhere, The Singularity of Bindings. | 12-May-07 15:51 |
| 2897 | Anton | It's interesting I stumbled the same way twice. Will I do it again in a year or so ? | 12-May-07 15:48 |
| 2896 | Gregg | That was my first thought. | 12-May-07 15:34 |
| 2895 | Anton | Aha! I know why. I seem to remember doing this once before. :) The SET gets its two arguments first, which binds the block twice, leaving the block bound to f2 before the setting takes place. | 12-May-07 12:40 |
| 2894 | Anton | Interesting problem: Why do I need BIND/COPY ? The aim is to copy the values of the facets in face F2 to face F1. f1: make face [] f2: make face [text: "hello"] facets: [text] set bind facets f1 reduce bind facets f2 f1/text ;== none ; <-- why ??? f1/text: none set bind/copy facets f1 reduce bind facets f2 f1/text ;== "hello" f1/text: none set bind facets f1 reduce bind/copy facets f2 f1/text ;== "hello" f1/text: none set bind/copy facets f1 reduce bind/copy facets f2 f1/text ;== "hello" | 12-May-07 12:36 |
| 2893 | Anton | Yes, that makes the most sense. | 10-May-07 16:32 |
| 2892 | Gregg | As Gabriele said, it's not just words, it's any value, because it's part of the value slot. >> val: first new-line/all [1 2 3] on == 1 >> head insert [] val == [ 1 ] | 10-May-07 16:26 |
| 2891 | Anton | and you can move the word into other series datatypes like path, then back to a block and see the new-line has followed it. | 10-May-07 15:49 |
| 2890 | Anton | >> word: first new-line/all reduce ['word] on == word >> head insert [] word == [ word ] | 10-May-07 15:48 |
| 2889 | Anton | I tested by extracting a word, then inserting into another block. | 10-May-07 15:48 |
| 2888 | Anton | So there must be at least one bit devoted to a new-line marker. | 10-May-07 15:46 |
| 2887 | Gregg | Excellent -- attributes of a value slot; that's clear. | 10-May-07 15:41 |
| 2886 | Gabriele | new-lines are attributes of value slots. values do not exist without value slots. rebol is always copyiing the 16 bytes of a rebol slot around... so it copies the new-line marker too | 10-May-07 15:39 |
| 2885 | Maxim | AFAICT line-markers are attributes of the "space in between" the content. using new-line we have complete, per-space control. | 10-May-07 15:35 |
| 2884 | Gregg | Interesting. I assumed new-line markers were liike pseudo-values in blocks. Thanks for doing the research Anton. | 10-May-07 15:29 |
| 2883 | Anton | Submitted the above bug to RAMBO. | 10-May-07 12:24 |
| 2882 | Anton | TO-SET-PATH is also affected. | 10-May-07 12:13 |
| 2881 | Anton | TO-PATH is affected the same way. | 10-May-07 12:10 |
| 2880 | Anton | It looks like it is. I was wondering where those new-lines were kept ! :) | 10-May-07 12:04 |
| 2879 | Anton | I thought it was an attribute of a block, but maybe it's an attribute of a word ? | 10-May-07 11:58 |
| 2878 | Anton | Makes me wonder how new-lines are implemented. | 10-May-07 11:57 |
| 2877 | Anton | I think it's amazing that FIRST returns the word with its hidden new-line attached. Very confusing trying to reproduce it again today. :) | 10-May-07 11:57 |
| 2876 | Gregg | I agree Anton. I imagine it's because paths are a block type. So we want to make sure it doesn't mess up other block types when fixed. | 4-May-07 16:23 |
| 2875 | Anton | I think it is an error, since I am molding a lit-path which can't be loaded back, because of the newline between the ' and the first word. | 4-May-07 13:52 |
| 2874 | Anton | This is the reduction: >> to-lit-path first new-line/all [word] on == ' word | 4-May-07 13:52 |
| 2873 | Anton | You are right. | 4-May-07 13:51 |
| 2872 | Oldes | foreach [style obj] svv/vid-styles [print mold to-lit-path reduce [style get in obj 'color]] | 4-May-07 7:34 |
| 2871 | Oldes | and why you use [style in obj 'color]? this will works as well: foreach [style obj] svv/vid-styles [print mold to-lit-path reduce [style 'color]] | 4-May-07 7:31 |
| 2870 | Oldes | foreach [style obj] new-line/all svv/vid-styles off [print mold to-lit-path reduce [style in obj 'color]] | 4-May-07 7:29 |
| 2869 | Anton | (The first one produces lit-paths starting with a newline - looks weird.) | 4-May-07 6:42 |
| 2868 | Anton | foreach [style obj] svv/vid-styles [print mold to-lit-path new-line/all reduce [style in obj 'color] off] | 4-May-07 6:39 |
| 2867 | Anton | solution/workaround: | 4-May-07 6:39 |
| 2866 | Anton | foreach [style obj] svv/vid-styles [print mold to-lit-path reduce [style in obj 'color]] | 4-May-07 6:39 |
| 2865 | Anton | Strange new-line bug/issue: | 4-May-07 6:39 |
| 2864 | Anton | Ok, very good. | 2-May-07 6:52 |