AltME groups: search

Compilation in working directory: I'm adding it in the todo list 
for the release.

Peter: thanks, then I'll add that to my todo-list.

I think it will take me one or two days for the 0.3.0 release todo-list 
to get done.

Wrinting a new blog entry is part of the todo-list. ;-)

Did not know, that todo-list contains also non-development related 
stuff :-)

BREAK is on my todo list. I might add CONTINUE too. GOTO could be 
useful for implementing fast FSM, but having some specific feature 
for FSM support would probably be a cleaner option than GOTO.


I personally very rarely need BREAK/CONTINUE, their usage depends 
on your programming style and the way you implement algorithms.

Gerard: reading the comments from your links, all the features people 
mention are on my todo-list for the Red IDE. ;-)

Preliminary path! and set-path! support added to Red interpreter.

https://github.com/dockimbel/Red/commit/53f87ff81822e81c5ddf56245e68f8e6255c698b


Works only on series! so far, function calls with refinements are 
next on the todo-list.

It's on my todo list to do more LOAD tests for R3. You can use those 
then, at least as a start.

Jerry: no, these are not yet supported. You can see what is missing 
for full floats support here: 


https://github.com/dockimbel/Red/wiki/Floating-point-support-todo-list

ah.. I see.. there is a TODO in the code

The dataype comparison matrix is on my todo list but I haven't found 
time to start on it yet.

I/O support for Red is very high on the Red todo list  - basic I/O 
support is essential for Nenad for Nenad to write Red/System V2 (which 
itself is essential for "production ready" Red.

Gregg, you have a fine taste of useful tech ;-)

I guess this is a huge task. If you look at the Xilinx ISE Pack and 
the prices they are asking...

There is a free Web version but this one only supports the very small 
units with max. 24k LC, not enough todo usefull things.

But of course a Verilog/VHDL dialect would be more than cool. Meanwhile 
OpenCL/CUDA would be nice as well.

@Bo: yes, the text related issues are not yet solved in the current 
R3/R3GUI versions(which also the ecapper uses). But are next on my 
"Android todo list" so you can expect them to be fixed in upcoming 
release.

btw, andreas any plans for a tokyo/kyoto extension? if so, I could 
strike this from my todo list otherwise I would start after posix. 
(asking just to avoid double work)

OK...I understand.  Will put on my todo list ... thanks.

Ryan, cool !  If you have any ideas for the design then feel free 
to suggest them, as the design is not fixed at the moment. Also, 
if there are styles that you feel the need for then suggest them 
and I'll add it to the todo list for consideration.

[1] Grouping of calendar events so you can filter select which type 
or with whom, specific calendar events are shared with, for display.
[2] Weekview in the calendar to fit more events pr. day

[3] Events from calendar formatted as a chronological TODO or activity 
list

[4] Export the calendar as HTML (it's a real problem if you have 
many events per day and can only see a small amount of them)

[5] Dynamic width of the user/group list to the left. Many group 
titles are chopped off.
[6] Filter search in the Users and Groups list

[7] Bigger/adjustable text area size in checklist entries, so it 
would be more suitable to store makedoc2 formatted documents in them 
(instant document repository!)

[8] Export checklists in makedoc2 format for integration in other 
makedoc2 docs

[9] Checklists as a column view. It would mean for Checklists: Spreadsheets 
that Checklists are in the left column and Spreadsheets are in the 
right column. You can select other checklists immediately without 
having to go back to the top and select a new one.

[10] Generally resizable windows everywhere. Small text areas are 
annoying!

:-)

don't know if that is in the todo list, but for exporting conversations, 
would it be possible to cover up email addresses?

Im really worried about this alpha thing, personaly i belive rebol 
is a great tool and i use it all the time, 

i know there is the time factor in development, but i belive there's 
no priority and the policy about TODO's 

it's crazy, on one side, services, view and graphics, sound formats, 
and on the other, multitasking, async ports, 

OSX support, and so many, many others... all taking place at the 
same time... 

We don't know what's first on the list, rebol changes as fast as 
developers type their code, 

(i dont  mean it in a bad whay, but still worries me) so todays 100 
lines may be tomorrows 10 

and so on ... why to spend time writing code on some issue will never 
leave alpha state, or even workst, be droped down 

some code will loose compatibility with newer versions and refuse 
to work, 

some other cobe, may become obsolete and old as soon we put it on 
the market, i think rebol has loose the KISS strategy. 

i know we love our 600K amazing tool, but don't be fool, this 600K 
don't mean is an easy and standarized 

development tool it's more like an other thing... ok it still is 
a cool tool, bla bla, but we must know 

there's a line conducting rebol upgrades, not just the crazy 600Kilobytes 
limit, 

it would not mind to my even if it whas 600 megas at this point this 
limit has loose the sence to be. 

i think here ideas come and go to fast, development has, in the last 
years, been embeed with the fashion of some lenguages, 

leave out the top then fight, we dont need it, just make it simple, 
i know rebol will reach maturity only if a srtight line traces his 
development

Ok, thanks, I added to todo list to check that out.

I'll stick it in the ToDo list. :)

Hi, has anyone any newer version of Todo List script? My intention 
is not to replace Qtask, just having something VERY easy, kind of 
check-list, for controlling tasks - http://www.xidys.com/rebol-view/image38.jpg

I'll add it to todo... if it's not there already. There might be 
compositing errors visible when resizing or something... can't remember.

Such a thing has been on my todo list for a while, but I've been 
a little busy lately with non-REBOL projects :(

Peter, Steeve, the original problem that started the parse proposals 
was the problem of complimenting charsets. However, it quickly changed 
to improving PARSE in general. Then, while we were waiting for the 
parse proposals to come up on the todo list, we came up with a better 
solution to complimenting charsets, which is not yet implemented 
and which is not limited to PARSE.

rebol [
	date: 24-Jul-2005 
	author: "Anton Rolls"
	comment: {

  Investigating why adding/removing 'merge from effect block seems 
  to change line-width on
		arc, circle etc.:

		ToDo:
		  - try to 

  - It looks like the AGG anti-aliasing is with the default window 
  background color ?

    When MERGE is added, then it's with the actual color that is merged 
    (seems ok and good to me).

    - so try to set b1/color so it's the same as the color anti-aliased 
    against in the merged version

    Perhaps default window background color (200.200.200) is close to 
    the default agg anti-aliasing color ?
		  (do not use custom window color)
		- try a simple LINE
		- report to RAMBO or AGG group
		- submit to RAMBO


  This shows that the addition of 'merge seems to add 0.5... (?) or 
  some scaled factor to the line-width:
	}
]

effect-blk: [
	draw [
		pen black
		line-width 0
		translate 25x25
		scale 1 1 
		circle 0x0 24 ;arc 0x0 24x24 0 270
	]
]
make-2nd-effect: func [/local result][
	result: copy/deep effect-blk
	insert result 'merge

 ;result/draw/line-width: result/draw/line-width - 0.5 ; <- even with 
 this they don't look quite the same

 result/draw/line-width: result/draw/line-width - any [attempt [correction-scr/data 
 * 0.1 + 0.5] 0]
	result
]
refresh: does [
	b2/effect: make-2nd-effect
	show [b1 b2]
	big1/image: to-image b1
	big2/image: to-image b2
	diff/image: xor big1/image big2/image
	same-txt/text: join "same? " big1/image = big2/image
	show [big1 big2 diff same-txt]
]
view/new window: center-face layout compose/only [
	across
	label 80 "scale"
	scroller 200x20 with [data: 1][
		change/dup next find b1/effect/draw 'scale face/data 2
		refresh
	]
	return
	label 80 "line-width"
	scroller 200x20 [
		b1/effect/draw/line-width: face/data * 4
		refresh
	]
	return
	label "line-width correction"
	correction-scr: scroller 200x20 [
		refresh
	]
	return
	b1: box 50x50 [refresh] effect (effect-blk)
	b2: box 50x50 [refresh] effect (make-2nd-effect)
	same-txt: text 200
	return
	big1: image 200x200
	big2: image 200x200
	return
	diff: image 200x200
]
refresh
do-events

not yet, but I have it on my 'todo' ;) ...will let you know in a 
few days.

R2-Forward has been released! Now you don't necessarily have to wait 
for R3 to get finished - use the new functions in R2 now :)

Released to DevBase (aka R3 chat) in Community/Libraries/R2-Forward 
(837). Tested in 2.6.2, 2.7.5 and 2.7.6. Take a look!

Stats: 72 words exported, 49999 chars, 41522 LM, 29730 LMF, 8379 
LMFC.


Obviously, there are whole categories of stuff that won't be backported; 
the notes say what is supported. You'd be surprised what I *have* 
managed to backport though - even some datatypes are spoofed :)


Discussions in R3 chat #837, or the Core group here. More testing 
is welcome - I'd like to push my tested platforms back as far as 
2.5.0 if I can. My todo list for R2-Forward is pretty extensive...

Hi all,


After learning a lot from you all I feel like I should contribute 
a bit.

On http://alain.goye.free.fr/rebol/or on Rebol Desktop's "AGReb" 
Reb site,
you can find:


- an updated version of %NoteReb.r, a REBOL tree-like notes organizer,
similar to and compatible with http://www.treepad.com/.

This new version of NoteReb.r has quite more functionalities; I use 
it to

work. A major bug seems to remain when intensively using the "undo" 
function
of Romano's edit-text-undo.r , which is quite nice despite that.


- a simple todo list, %todo-ag.r, which orders tasks by priority 
based on
their importance, workload and deadline...


If anyone likes these please drop me a line, and if you improve them, 
all
the better!

Alain.

I think blitting is already in the todo list so stay tuned ;)

shadwolf: It's on my (growing) ToDo list. ;)

Brock: validation is also on my ToDo list (you can see the beginnings 
of it in the field widget character length limits). A couple of questions 
though (both how it is done in .Net and how it *should* be done in 
RebGUI):

	What's the granularity of the validation?

 Does it allow the specification of a mask (e.g. for phone numbers)?

 Is it validated as I type, when I leave the field, or when I save 
 the form? (Or is it flexible enough to let me choose the level of 
 validation?)


shadwolf: Haven't really thought about it much, but I figured the 
tab-panel redraw feel was a logical place to do the work.

TODO: 
* Vertacal and Horizontal scrollers management
* Column content resizing management (internal & external)

* Line Selection with a filled fill (not sure of the wanted way to 
make this work ...)
* Inseting rows 
* Deleting rows

* More widgets support (for the moment I can handle images checks 
and texts)

So how to best handle data now? For example I want to handle a todo 
list, where I need to change position of the todos in the list. Does 
the widget works with copy of the data best, or can I link it directly 
with the data block that the other functions work with too?

Luisc: It's on the ToDo list. From the release notes above:

	Known issues
		...
		- edit-list needs auto-fill logic added

Anton

 1) Design decisions: thanks; if you think any of them were *bad* 
 then let me know, that's the reason it's still alpha ;)

 2) I like the edit-pair demo, I'll look at adding a cut-down version 
 of it to %tour.r

 3) Versioning / caching was something I was going to look at once 
 RebGUI goes beta and / or we have more of a handle on how REBOL/Services 
 works.
	4) "local" face definition: good point, added to next build.

 5) Extending widgets object: Yes, RebGUI doesn't have a "stylize" 
 system so you have to extend the widgets object when you need to 
 add your own. My hope is that with a functionally rich set of widgets 
 this will be the exception rather than the rule!

Robert

 Action handler not yet added to table widget. I'll add odd/even coloring 
 to the ToDo list.

Volker

 [face value] - less important for RebGUI as face/text or face/data 
 covers almost all cases; but I'll think on it a bit more as the compatibility 
 aspect is worth considering.
	/init - I'll look at making this a block in the next build.

 event-func removal - I'm considering a "load-time-flag" as you suggested
	system/standard/face - as per comments to Anton above
	"If there is ..." - agree fully with everything stated here ;)


RebGUI development is taking a slight pause until View 1.3 is released, 
as I want to baseline against that and remove all the pre-1.3 exceptions 
that have crept in.

a bit off topic: iTunes has a widget for rating of songs with stars 
one to five. Basically it's a widget that has 5 different states, 
depending on where you click on it. Would that be on the todo list 
for RebGUI? I'm planning to have such a thing in my next rewrite 
of my listview, I showed you some time ago.

Robert

 Docs: the 'Widgets' section of the 'RebGUI Display User's Guide' 
 is already in the Repository (the WidgetList Wiki entry) ... I'll 
 be removing that section from the guide once all the widget details 
 have been copied across. Feel free to update the Wiki with any widget 
 specific usage notes / instructions. Forward any other doc changes 
 to me and I'll put them in. I plan to eventually move all the docs 
 across to the Wiki, just haven't got around to doing it yet.

 "do you first want to take a look at the changes or should I just 
 check them in?" ... Just check them in thanks.
	screenshots: added to the ToDo list

 widget placement: I'm coming around to the idea that BELOW may be 
 unavoidable, even if undesirable from a design / complexity POV
	tabbing: Anton about summed it up

Volker
	Type: also used by accessor functions

about "I don't want to write it myself" - we're lucky that some of 
us don't think like that (i.e. nenad's mysql:// and so on...) :-) 
but anyway, if you need it, and are even ready to pay for it, i'm 
quite sure that you'll be able to find a rebol developer willing 
to do it for you... I can't speak for RT so I can't tell you if we 
are gonna do it or not; i think REBOL's SSL implementation needs 
this functionality, but there are so many things in the todo list...

next on the list of todo's is to separate top and bottom notes and 
timings and add in rests.

Another option is to select the rowid(s) you are after:

	id: db-select/where rowid table [...]

then perform the operations you want:

	db-update/where ... compose [ ... (id) ...]


BTW, thanks for the feedback on both RebDB/RebGUI ... always good 
to know where folks are having both success and problems. More demos/tutorials 
are on the ever growing ToDo list. ;)

Not yet. It's on the todo list.

IMO rebrowse should be far away in our todo list. So much core capabilities 
was missing in the first R3 released.

When i read that for Carl, [parse] evolutions must be downsized the 
most as possible (while I believe this is one of the most important 
functions 

in Rebol), i have still some doubts how priorities are well defined.

On my todo list.

Pekr, Brian has a very very long todo list :)

I expect that my work on some of my todo list will take the form 
of helping others do it - it's more of a to-get-done list :)

However, I was not precise enough about my todo list. No REBOL interpreters 
are on it - I want a REBOL-to-JS compiler.

R2-Forward has been updated to match alpha 37 as well, though that 
meant adding one more function to the todo list (and 5 more to the 
done list, and 6 more to the improved list) :)

The function I added to my todo list yesterday is done. Two lines 
of code, though they are tricky :)

The new DevBase (3) mostly works now. I posted some suggestions today, 
but it is usable as-is. I'm only using DevBase 2 for historical reference 
now. DevBase 3 doesn't have a reviewer concept, so I'm going to ask 
Carl what the new acceptance policy is - I have the rank to accept, 
but the guidelines need to be updated for the new model. Most of 
my todo list for DevBase 2 is already implemented in DevBase 3, so 
in many ways it is already a vast improvement.

There are some gotchas - I didn't redefine any R2 natives in the 
main module. That is on my todo list for a suplementary module.

Not with the term. Cleaning up R3's modularity is the next thing 
on the todo list, and I will backport it to R2-Forward as much as 
possible. Most of the hard work of the backport has been done already 
by Gabriele in his %module.r. By the way, if you don't use R2-Forward 
as a module, a lot more code doesn't work. The new words are just 
exported from it when loaded as a module - they redefine the global 
words when you just DO it. Those changes to global words can break 
other parts of R2 in unknown ways. If you just import the module, 
only the words in your script are redefined, so only your script 
has to be made compatible.

Anton, the --do bug is known, cross-platform (not just Linux), and 
part of a half-dozen bugs that can be fixed by rewriting one function. 
It's the next R3 thing on my todo list, when I get the chance. I'm 
swamped with work at the moment.

BrianH, cool, that it's next on your todo list - glad you've noticed.

It's on my todo list, no html though.

To write a rebcode replacement all you need is user-defined types 
and the knowhow - it's on my todo list. However, user-defined types 
will probably need to be defined in plugins, and at the very least 
we couldn't even specify how to define them without a working plugin 
model. So it will help, indirectly :)

Yes. And a satisfaction to checking it off on the big todo list. 
;)

We need a way to make the "todo list" accessible and we need users 
to help us maintain it.

Pekr, for some things, I need more of a todo list rather than message 
thread.

I'd like to have one also, it's added in the todo list.

Terry, in my todo-list, I have a generic module for interfacing cheyenne's 
HTTPd with REBOL applications called mod-map-url (or mod-mapping). 
It will map predefined URLs to REBOL objects. Example: http://domain.com/app/show
will call the function ''show from your object 'app. This module 
should cover most of needs if you have to embed Cheyenne in your 
REBOL application. If it doesn't cover your specific needs, you'll 
have to write a specific mod_xyz HTTPd module, which might be a little 
more complex.

AddHandler: it's on my Todo list for 1.0 :-)

In the meantime, I have also on my todo list a dedicated web site 
for Cheyenne. I'll work on that in the next days.

It's not on my Todo list, I plan to make a higher level framework 
for building web applications, where I don't want to mess anymore 
with HTML or Javascript. Kind of VID dialect that compiles to HTML+CSS+JS.

SID & session/start : I've added that to my todo list, need to think 
about that deeper before implementing.

Graham: you can set your webapp (or at domain level) in debug mode 
(using the 'debug keyword in config file). If the debug mode could 
be tested, it could allow you to enable/disable the captcha system 
(or anything else) based on the working mode (debug / in production). 
I'll add that to the todo list also.

:-) Anyway I'll add BA on my todo list.

There's no way to have the debug mode without the debug menu currently, 
but it should be easy to add an option to define the debug level. 
I'm adding that to v0.9.20 todo list (scheduled for releasing before 
the end of this month).

Graham: I'm putting this issue higher in my todo list, shouldn't 
require much work to make it fully multi-instance safe.

Re: JS warning in Firebug : that's intentional, it's not a bug, but 
it is bad practice. I'm putting that in my todo list.

Sounds useful, adding your RFE to my todo list.

True about the tunneling tools, but I'm not the server guy so I don't 
know why they are still using Apache for the main site. I know they 
aren't married to it since the site isn't built on unique Apache 
modules, and because they mention looking at other servers. It wouuld 
depend on performance and scalability, so an alternate soltion would 
need to outperform and outscale Apache and FastCGI. As for the RSP 
features Maarten is adding, don't know what they are yet - it's on 
my todo list to compare the two RSPs to determine if there are features 
that the other could use.

Well, there's just a local dependency on config file to remove first 
(in my todo list) to allow remote worker process (for RSP, CGI,...). 
But you need a also a remote process manager to handle the launching 
of worker processes. Anyway, I think that using a front load balancer 
(supporting session affinity) with several servers is a simple and 
efficient solution.

No, but it's in my todo-list for the next release (0.9.20).

I've noted in my todo list to extend the RSP API to be able to add/delete 
jobs (for now, the list is static, loaded from config file and cannot 
be accessed from RSP).

But it seems that you're not using webapps, just plain RSP and manual 
session handling. You should know that invoking session/start container 
will create a new session context but you won't get a new ID at once 
(session/id will be set to none until the RSP page ends). We already 
discussed this point previously and I have an entry in my todo list 
to improve that. (it requires a change in the session ID creation 
process)

Pekr: that's in my todo list, I just need to find some free time 
to think more deeply about how to support such feature efficiently.


Btw, I have built a XMLC (XML Compiler) engine inspired by enhydra 
(http://www.enhydra.org/tech/xmlc/index.html) which should fit perfectly 
your needs. It's a working prototype but need some significant work 
to be integrated within Cheyenne, so it's low priority for now.

Set-cookie is on the todo list but hasn't been implemented yet. So, 
for now, you have to set http header manually.

improved debugging : on my todo list. I might try to emit the debug 
info to a JS console like Firebug's one or a custom one.

Janko: I have in my todo list a full virtual system to add to Cheyenne 
allowing embedding webapps in a encapped Cheyenne. It can be done 
by replacing every filesystem accessing functions (DO, LOAD, READ, 
WRITE,...) by custom ones getting files from memory. The hard part 
is to integrate such approach within Cheyenne preserving perfomances 
for normal filesystem accesses while avoiding redundant code, this 
needs time for designing and prototyping.


I can't see an easy way to protect you webapps right now, but maybe 
other might have found a way to do that?

To make things clear for all, I'm still actively working on Cheyenne 
and CureCode. I have a long todo list for both of them (including 
new frameworks for Cheyenne) and intend to continue with it.

Kaj: "Cheyenne doesn't seem to load its MIME definitions from the 
standard location on Unix systems, %/etc/mime.types, loading an internal 
list %misc/mime.types instead"


Yes, it was done that way to ensure a common base of mime-types across 
all OSes. Anyway, I have in my todo list an entry for such a feature. 
I'm not yet sure if it should be by default, or controled by an explicit 
option.

Graham: a few links about your question: 

http://en.wikipedia.org/wiki/Transport_Layer_Security#Support_for_name-based_virtual_servers
http://en.wikipedia.org/wiki/Server_Name_Indication

SNI is in stunnel's todo list: http://stunnel.mirt.net/?page=todo_sdf

webapp.exe is on Doc's todo liset

hehe - you found my todo list - i didnt have to write it after all 
:)

Looks good.. but we first must finish the Flash version anyway. I'm 
now working on level 11 so at least another 11 still have todo.

I'll add that to the todo list for next release.

There's no UI for that list. I'll do it by hand right now and will 
note that feature in the todo list.

Good point, the "By submitter" filter is not fully implemented yet, 
so not really working. I've added that in my Todo list and will see 
next week if I can improve that quickly.

Added in todo list. Should be easy to implement.

Looks like there's a consensus. I have a few improvements pending 
for CureCode to be done this week, so I'll add also this new rule 
to my todo list.

REVERSE, LIMIT and OF (but renamed I hope) are still on the todo 
list, and I really want all of those. My biggest pie-in-the-sky requests 
have been done though (with the exception of USE, which I have a 
workaround for).

Why not say TODO then? ;-)

If I knew how to do this, it would be done already. Learning how 
is on my todo list, but I'm hoping someone else (like you) gets to 
it first.

For most people those distinctions don't matter, they can just call 
it chat. It matters to me because writing another DevBase client 
is on my immediate todo list.

Oh, sorting the todo list. No, the license isn't at the top.

according to the above example I would like to store the binary via 
a tcp.

any other possibility to transform the binary? while  using enbase 
I have 
also todo a dehex after retrieving. would like to avoid this.

Andreas? Learning git is still on my todo list for this week.