AltME groups: search

0) multiple fallback mechanisms for getting/staying connected.

1) absolute control of what is actualy removed from local machine... 
ever.

2) better support for using a single account from several machines.
3) better support for using several worlds from one computer.

4) finer control of what posts you are exposed to. (groups and users 
and users in groups) 
5) filesharing
6) api,locks, so we can muck with the filesets.

7) calendar,just fix it up. hour/day/week views, sorting,repeated,various 
alerts ...
8) adjustable font sizes

9) search should return hits (the text) from further back than your 
message buffer limit.
10) OSX support & recycle bug

for dictionary sorting it is sufficent that first "1000"  is less 
than first "99"

Logic! works fine if you have unique key values.  +1 0 -1 is for 
ensuring stable sorting when key values are not unique.

; Sorting Unordered Key/Value Pairs

;unordered key/value pairs, keys in each record aren't in the same 
order
data: [
	[fld1 "c" fld2 "1" fld3 "b2"]
	[fld1 "b" fld3 "a1" fld2 "3"]
	[fld3 "c" fld2 "2"  fld1 "a"]
]

; sorts on first text found, value is not sorted
sort data

; notice reverse sort on first text found, value is not sorted
sort/reverse data

; sort on value for fld1 key - ascending order
sort/compare data func[a b] [a/fld1 < b/fld1]

; sort on value for fld1 key - descending order
sort/compare data func[a b] [a/fld1 > b/fld1]

; sort on value for fld2 key - ascending order
sort/compare data func[a b] [a/fld2 < b/fld2]

; sort on value for fld2 key - descending order
sort/compare data func[a b] [a/fld2 > b/fld2]

Okay, I think I am following.  If my parameters to the function were 
numbers, then using the [sign? a/1 - b/1] would provide a more accurate 
sort due to the tri-state return of the sign? function.  However, 
since I am sorting strings and can AFAIK only compare using <>=, 
are you suggesting I should test all of the states and return 1,0,-1 
as appropriate?

You got it!.
And a little shorter, and maybe faster:
  [ if a/1 > b/1 [return 1]
    if a/1 < b/1 [return -1]
    return 0
  ]

Of course, you only need to worry about stable sorting if you have 
duplicate keys and need to retain the original entry sequence for 
them. Other wise [return a/1 < b/1] is fine and fast.

I mean the middle of the three fields, sorting a 3-field record:
  sort-func: func [a b] [return a/2 < b/2]

  sort/skip/all/compare [99 10 2       98 11 5        97 12 4] 3 :sort-func
== [99 10 2 98 11 5 97 12 4]

To Gregg,

The diff algorithm I am using ... 

2 blocks, one for reg-data-old (block1), the other for reg-data-new 
(block2).
data in these blocks are in the following format:
   [ key1 value1 key2 value2 key3 value3 ... ]
   where keyX and valueX are both strings. 
Example:

   [ "HKEY_LOCAL_MACHINE_SOFTWARE_ABC"  {"sid"=dword:00000001^/"tid"=dword:000000FF} 
   ... ]


I use "SORT/SKIP 2" to sort the 2 blocks. It's very fast, I guess 
that's because the original data are in order already. After sorting, 
I can comapre these two blocks with the "race" algorithm. 

The "race" algorithm is very simple ...

loop [
    if ... the key in block1 is equal to the key in block2 
    then ... check their values (different values mean modified) 

    if ... the key in block1 is less than the key in block2

    then ... the key in block1 is deleted-key. Move the key in block 
    1 to the next key.  

    if ... the key in block1 is greater than the key in block2

    then ... the key in block2 is added-key. Move the key in block 2 
    to the next key.  
] 


Well, my English is not very good. I hope you understand what I am 
saying here.

I guess I don't after all. I still can't get it to recognize 'b. 
If I try to probe 'b inside the function, sorting just stops. probing 
'a works fine.

Sorting: you may be able to adapt this hungarian code:

http://www.rebol.org/cgi-bin/cgiwrap/rebol/ml-display-thread.r?m=rmlMWWJ

It seems like the memory manager is getting list! nodes from a common 
pool, and then SORT is messing up the rebuilding of the list and 
putting random data in the post-sorted list during the sorting process.

I thought this was actually mentioned in the docs. I read some place 
once that sorting and some other functions were never meant to be 
used with list!. I think it's in the appendix of the Core documentation 
somewhere.

I looked around a bit and couldn't really find a good solution.  
Is there an easy way to reorder a block that's not sorting it - To 
just move one element.  Say my-block: [a b c d e]  Is there a function 
to just move c to the front of the block, or to push it to the back?

skiping a block has no cost (no data modified), sorting has cost 
(data modified)

but not if he's sorting data with a skip size equal to the span

However, sorting the index won't change any of the references that 
the index is pointing to, because the underlying data doesn't change. 
Once you are done sorting and manipulating your index you can commit 
the changes, which means building new data from the index references.

and yes the span (# of columns) is the same  for sorting and skipping

Henrik - auto function - you will add small icon to the header (like 
there is for sorting). It will be drop-down (combo?) style. You will 
fill-it-in with unique values for particular columns .... (in your 
example Gui tools, bug database, HVIT ...., selecting one will show 
only those related items) ...imo that is what Robert means here ....

ok, haven't gotten very far yet, but http://hmkdesign.dk/rebol/list-view3.r

my attempt at a list view based on custom faces. more will come during 
the day... basically only fills out values and the sort buttons react 
visibly, but no sorting happens yet.

sorting works now. click the button in the upper right corner to 
reset sorting

sorting also works after filtering

Nice! Maybe it would be better to have situation similar to Lotus 
Notes grid? They show thin arrow, if the column is sortable (not 
all are). Then you can sort it up and down and third click deactivates 
sorting. It is kind of natural ...

well, not in our case. But with some older db systems, like xbase 
in DOS, we just had this facility. Not all columns were indexed. 
Sorting non indexed columns was not allowed ...

tristate sorting now available. can be turned off with the TRI-STATE-SORT 
variable.

back again.... fixed a bug where resize didn't work during filtering 
and incorrect amount of results when filtering and turning off sorting

0.0.6 uploaded... minor bugfix to keep the selected persistent even 
when sorting and filtered.

robert, BTW tri-state sorting can be turned off with the TRI-STATE-SORT 
variable. then it only switches between ascending and descending.

sorry for the wait... Version 0.0.8 uploaded

Changes:

      New: Functions to select next, previous, next page, previous page, 
      first and last. Uses FOLLOW.

      New: FOLLOW. Automatically follows the selected entry so it's always 
      in view. Requires FOLLOW? set to TRUE

      New: SCROLL-HERE. Scrolls automatically to the selected entry.
      Fix: Filter result was lost after resize.
      Fix: Sorting was lost after resize.
      Fix: Sorting indication is now persistent after resize.
      Fix: Dual state sorting was accidentally broken.
      New: Initial sorting can now be set before first view
      New: Right-click on header unsorts the list

Demo can be found at http://hmkdesign.dk/rebol/list-view3.r

Version 0.0.9 uploaded

Changes:

      New: GET-BLOCK retrieved the selected data as a block. Only works 
      with shift for now under multi and multi-row.

      New: Using the shift key, you can select multiple cells in multi 
      and multi-row mode.

      New: Five different select modes now: Single, multi, row, multi-row 
      and column.

      Fix: SCROLL-HERE only works with select modes 'single and 'row

      Fix: FOLLOW didn't work when selecting a row and then sorting


The different select modes might be interesting for a future spreadsheet 
face.

anton:

First one: Alright. :-)

Second one: All that code will be thrown out and there will be a 
different demo later

Third one: You have a point. I'll look at the issue of sorting standard 
vs. custom facets.

the AGG part... right. the sort button uses AGG to display the sorting 
arrow. I could make that into an image and do some tests on an older 
View and see if it can run there...

resets the sorting mode to 'nosort

LIST-VIEW version 0.0.16 uploaded.

Changes:

      Fix: LAST-CNT crashed on empty SORT-INDEX after filtering

      New: FILL flag to set whether or not to paint all rows in the list 
      view

      New: COLORS/4 contains the color of the background behind the rows.

      New: When resizing OUT-COLS in runtime, WIDTHS is reset to default 
      values

      Fix: Columns can now be appended or removed to OUT-COLS in runtime
      Fix: Changed behaviour so that DATA is always treated as
        a block of blocks if manipulated by LIST-VIEW itself.

        Only external input of a single block value can change this.
      Fix: INSERT-ROW-HERE, REMOVE-ROW-HERE, CHANGE-ROW-HERE
        failed on empty DATA
      New: Stricter typechecks on manipulation functions
      Fix: Values are now copied into DATA
      Fix: Sorting did not work, when using only one DATA column

      New: Allows using keyed blocks as input for manipulating functions.

      Fix: Header size now calculated with OUT-COLS also, which removes 
      a crash
      New: Created a test suite in file list-demo.r
      New: Moved demo code out of this file

    Main file is available at:
    http://www.hmkdesign.dk/rebol/list-view/list-view.r
    Demo and testcases available at:
    http://www.hmkdesign.dk/rebol/list-view/list-demo.r
    Docs are available in makedoc2 format at:
    http://www.hmkdesign.dk/rebol/list-view/list-view.txtand
    http://www.hmkdesign.dk/rebol/list-view/list-view.html

yeah, however there might be a slight confusion: Currently the -HERE 
functions take in account filtering and sorting, so that you always 
edit or retrieve the right row regardless of these settings. the 
other functions get and put directly in DATA. The behaviour would 
either need to change or I'd have to add another refinement

suggestion:

insert-row - would add a row at the selected position


insert-row/at - would add a row at the position that can be seen 
in the list after filtering and sorting


insert-row/at/direct - would add a row directly in DATA at the position

insert-row/direct - would be ignored? (I don't like that)

there's a filter isn't there for sorting out code from application 
problems?

next step is implementation of the gross-level polygon proximity 
test (a fast algorythm ignoring polygons which are too far away). 
 


this allows many polygons to live in the same scene without requiring 
collision tests for them.


I'll probably use a double linked-list for X and Y sorting of polygons. 
 this allows us to start at our position directly and spread the 
search on each side of the list (in both directions).

has anyone played around with SAT systems before?  or with spatial 
sorting algorithms?

MAJOR milestone for Game kit.


test app updated and includes multiple shape collisions and propagation. 
 quite fun  :-)

also: press g to view spatial sorting grid, its a bit mesmerizing 
to see


do http://www.pointillistic.com/open-REBOL/moa/files/ctest-preboled.r

Sorting.....Check this thread. It contains worked solutions for correct 
sorting in Hungarian. French should be similar:

http://www.rebol.org/cgi-bin/cgiwrap/rebol/ml-display-thread.r?m=rmlMWWJ

Surely French rebolers have dealt with sorting... Have you checked 
rebolfrance  ?

For A) just pointing to someone who happen to have access..  Near 
start of the document   " it and report it in [CureCode]]. "  looks 
to me there is one braket missing..  


For the B... it was related to this Unicode-sorting problem.  After 
some digging I got the impression that Rebol uses Utf-8 as a internal 
string format even at runtime. It will make comparisions quite costly 
operations since the strings must be (at least as far as I can understand) 
be expanded to 16/32 bits/char before comparision.  I do assume this 
is well known (undocumented) issue and accepted tradeoff (trying 
to optimize size)?

in that case sorting them from long to short to begin with will foil 
recursive macro rxpansion

THE docs come from pdf's that I have converted to text and tried 
to reformat by hand to hte similest form whilepreserving the structure 
of the doc. In addition to sections, sub-sections and sub-sub-seections 
there are nubered lists, letter lists, photos/diagrams, and tables 
to deal with. I thought I start with sorting out the sections and 
tackle the rest later.

Phone book sorting - that's really complex :(

It is my pleasure to announce, that Cyphre was contracted to bring 
what I regard latest limiting factor for RebGUI database experience 
- a grid. The grid should support following features - visible/non-visible 
columns, both vertical/horizontal scrolling, keyboard support, programmable 
navigation, tri-state columns sorting, possibility to put other styles 
in cells. Expect it being in the middle of capabilities of RebGUI 
table, and Henrik's grid. The grid should be also easily portable 
to VID. The license - BSD.


Other things Cyphre will look into with regards to Rebgui is, how 
to make RebGUI a bit more pretty, centralising other things or simply 
allowing gradients for tabs etc. That is subject to change.


On non RebGUI front, we should have better sys-tray support under 
Windows, probably via .dll ....

The time-frame is three weeks from today. Stay tuned!

< QM > Version 0.3.9

http://www.ross-gill.com/QM/


Fixes a context issue with QuickTags (bug fix).  Minor change to 
the Cheyenne 'request/content' handling (bug fix).  And thanks to 
Ammon for giving it testdrive, helps greatly in sorting out priorities!

I would like widgets tabling, statusbar, menu, table with free content 
(not only text) colomn resizable and sorting, menu, popup menu,

sorting, text, field, image, check, info

* Sorting ;)

According to ashley advice the new data organisation is faster and 
it will be easier and fast for the sorting algorythm (still not implemented 
in rebgui-list3.r ;)

listview: Pretty cool :-)) Some ideas:

- add a line highligh feature for the selected line and the line 
the cursor is currently pointing to

- double clicking the column-resize bar resets the column width to 
the default value

- add an up/down arrow to the column which was used for sorting, 
to indicate sorting order

robert the problem you see with selected line and sort is because 
to speed the sorting process I change the widget field (text, data, 
image) content and so they conserv there index. What I need to do 
to not loose perf is to change the actual color seek the picked content 
and pass to the select-line function the new index ;)

Ichnaged the over function content for header buttons too ... now 
it shows/hide the sorting indicator

ordering = sorting order = sort sorry false friend with french work 
ordre ;)

Column resizing and sorting now work correctly. In addition a number 
of useful accessor functions exist to more easily manage the data. 
From the online doco:

5.24 Table


Columns and rows of values formatted according to a header definition 
block.

Specification
 	action	block to execute when an item is selected. 	
 	data 	block of values. 	

  options 	Optional multi word followed by column header entries in 
  the form: 	
		string specifying column title
		word specifying column alignment
		decimal specifying column width as a percentage

Runtime
 	data 	block of values to display. 	
 	picked 	block of currently selected row number(s). 	
 	selected 	block of currently selected data. 	
 	redraw 	function to redraw widget after data changes.

One problem is sorting; You need to extract the row you need to use 
for sorting, create the sorting sequence and rebuild the block. Or 
is there a faster way?

table: if a column has the width of the sort arrow, it's no longer 
possible to change sorting order after clicking once.

Gregg, I totally agree. And it's one of those things that drive me 
nuts in VID / View. Sorting faces for z-ordering etc. is really no 
fun. And I have no way to get a reference that's stable.

but so far, I am very satisfied, the grid does tri-state columns 
sorting, functions for insert, remove, swap columns were added, you 
can have whatever element in cell, etc.

currently functions like - swap-columns, insert-column, remove-column, 
work with real data block, whereas sorting column introduces virtual 
adressing. You can still access raw data by going to grid/content/2/2 
or so, but if you want to get sorting reflected, you need to use 
API ....

also I don't really notice slow downs on very large arrays, because 
I always work from a sorting index, a plain 'pick of the row need 
from the data array. this is pretty fast.

if SHOW was much faster, LIST-VIEW could be insanely fast. you could 
probably easily scroll a 50x50 array in fullscreen 1024x768 at 25-40 
fps. I've noticed that when doing manipulations when not updating, 
such as sorting and moving entries in one go, these things are close 
to instant. The MOVE-ROW-UP/DOWN operations work like that.

And, I find it simpelst to have the data on the screen and in the 
program in sync. Sorting should alter the data block as well. If 
I pick the first line, I want to pick the first record. Of course 
using an API for indirection is OK too. But than do it always and 
for everything. No direct access to the record data.

getting a 5 second delay
 Got it. Hard to believe, but:

	write file form sort unique dict

is about a hundred times slower than:

	write file form dict


Sorting isn't so bad, but unique absolutely grinds it to a halt. 
Timings are:

parse		00:00.2
plus sort	00:00.8
plus unique	00:05

a little suggestion.


the current cookbook page at , http://www.rebol.net/cookbook/, needs 
to have better tagging for sorting and searching purposes.

Example. An example can be tag to 'view', 'cgi', 'ios'


Or, we can break it up into 'logical chapters in a book'. Example

1. Part I. Rebol Basics
2. Part II. Advanced Rebol
3. Part III. /View Basics
4. Part IV. /View Styles
5. Part V. /IOS
6. List of Examples

Re: Chris's order note (#5  of http://www.rebol.net/altweb/rebol3/chat362.html) 
 

This javascript http://www.kryogenix.org/code/browser/sorttable/
allows local sorting of an html table  by any column heading. 

Perhaps it would allow ordering as the client wants in the altme 
extract.

I'll give a shot at sorting out all of rebol.org once I get basic 
capabilities going and report back here, when its done.

things like list sorting in widgets like table or listview in rebgui 
could profit form rebcode optimisation

My base is not hardwired, but an argument. Will be usually 0, 1, 
but could be other vlaues too. -1 would give three-state if. nice 
for stable sorting maybe.

does sorting Czech require Unicode?

that was Gabriele who asked about sorting and if it needs unicode 
... we need unicode for rebdb though ...

rebol's internationalisation support is pretty weak in that regard

 - if you mean that REBOL does not support Czech sorting, then you 
 are right. Otherwise Rebol supports Czech coding supporting ISO Latin 
 2 as mentioned above

what a crap - I stop buying Creative stuff. If some company can't 
innovate, they should shut-up and leave the scene. How can anyone 
with good brain condition patent such a thing as sorting based upon 
ID3 tag content?

In Dbase, the date was stored in db in YYYYMMDD, so I vote for the 
date storage change too ... really helps sorting ...

Ah, ok. How about sorting in Rebol? Does this help?

Putting this into SQLite would require, that we add those country 
specific sorting rules at the C level and provide a Rebol call, so 
select the correct sorting.

Do you have any references to an country specific sorting implementation? 
Than I can take a look how to add it.

SET-SORTING-MODE "CZ"

I want to sort in SQLite. But then you receive your recordset to 
REBOL, you put it into grid for e.g., which has facility for sorting 
columns. Then you press particular column, and grid sorts your result 
recordset using rebol's built in 'sort function ... and the result 
is wrong ... (well, but this is minor issue, the importance is to 
get correct resultset from the query. I just tried to say, that R3 
has to address some localisation principles itself too ....)

The sorting problem with collations applies to Unicode, not just 
UTF-whatever, so it is a problem. Mostly a problem of size: The actual 
colation sorting code is small, but the collation data is large. 
Add more than one or two and REBOL gets huge.

A solution would be to move the sorting out into the host code, where 
it can be made to use any system-specific sorting code, which should 
work for platforms with good Unicode support like Windows, OS X and 
some Linux distros. The problem with that is that the data would 
probably need to be migrated to the host format before the host routines 
could be used; string! is not UTF-8 or UTF-16 internally, it is UCS-8 
(in theory), UCS-16 or UCS-32 (in theory), all fixed-length encodings. 
That would add a lot of overhead to sorting.

Jamie, that was referring to using a hash as a table rather than 
as an index. If you use a hash rather than a block for your table, 
all of your searches would be faster without needing any seperate 
indexes. The only way to have the speed of searching a block be comparable 
would be to keep it sorted and use a binary search (what RebDB does 
I think), but that doesn't help much with multiple keys that require 
different sorting orders.


On the other hand, I've been sold on the idea that when you use a 
hash as an index (rather than the table), you are basically using 
it like an assoc, so using a structure optimized for that behavior 
would probably be best.

sorting is different then?

yes, there are some design issues in that style creation is too complex 
and must be simplified. Carl and Gabriele are sorting that out in 
private.

Ok, I'm building it of several parts. (This may change if I find 
some more clever way of doing it.) First there is a DATA-GRID, which 
is a TIGHT style that contains actors to generate a grid view and 
links to a block of data. DATA-GRID is a slave style in that you 
link it to a data block and then it will display what it can display 
of that block from a start index set in the style, so it works like 
a data window. TEXT-GRID is currently just a variant of DATA-GRID 
with different spacing between cells.


Next, we can move that start index around by attaching a scroller 
to the DATA-GRID, and set the DATA-GRID's ON-SCROLL actor to set 
a new index, based on the input from the scroller. The scroller will 
be set based on the size of the data block versus the size of the 
data grid. Presto, a functioning list view.

I will explain sorting, filtering and all that later.

If I get to do it, sorting will be non-destructive, like LIST-VIEW. 
This means keeping a sort index. But that depends on how complex 
it will be. Carl tolerates only little complexity.

you have to worry about encodings when you do conversions. i don't 
see where the R2 server is doing any of that. Also, with UTF-8 there 
is no need to worry about encodings on searches and things like that. 
The only issue could be sorting, but that is also region specific 
so it's a completely different issue that R3 cannot solve globally 
either.

Of course FOREACH of map! would operate in the order that TO-BLOCK 
map! would return the keys and values at that moment. In the long 
run you would have to consider the order of FOREACH map! to be non-deterministic 
between calls. The map! type has no inherent ordering, so position 
and sorting are meaningless for it.

The sorting order should handle priorities, and the difference between 
word, /word, "word" and word! usage should be enough.

Adrian, what Brian is proposing will get you most of what you want, 
but what you are asking for seems to be a bit to specific and from 
my perspective doesn't add enough value to be worth the time to implement. 
 With intuitive sorting you'ld get all of the functions that require 
both an Integer! and a String! first followed by those that require 
an Integer! or a String!.  About 80% of the reason that I actually 
use Help is to see the order in which a function expects it's arguments 
to be in.  Searching for [Integer! String!] will list the functions 
that opperate on a string and require an index to that string at 
the top of the list and I think that's what you're really looking 
for.  Some people think in oppisite directions and want to declare 
the index first and others want to declare the string first.  It's 
just a matter of preference and doesn't change what the function 
does.

While I have your attention and I'm thinking about sorting I just 
thought I'd mention that I'm using the following work-around for 
the lack of /compare in sort:

; R3 /compare bug work around
sort-compare: func [
	blk
][
	; disorder the rows
	forskip blk 2 [change/part blk reduce [blk/2 blk/1] 2]
	; sort em
	sort/skip/reverse blk 2
	; reorder the rows
	forskip blk 2 [change/part blk reduce [blk/2 blk/1] 2]
	blk
]

Curecode new release : 0.9.1 - http://softinnov.org:8000/curecode/

Changelog:

	o Localization framework (english and french catalogs provided).
	o ChangeLog page added.
	o Ticket history added.
	o Tickets list sorting added.
	o Numerous bugfixes (see CureCode project)
	
Needs Cheyenne 0.9.16 (to be released soon).

Package download URL : http://softinnov.org/dl/curecode-r091.zip

Looks nice.  I noticed that on column sorting, depending on the sort, 
columns resize differently.

Thanks. 235 is all of the current stuff - the "worst severity" is 
a sorting criterium.

Dockimbel -- could we have some way of searching (or sorting results) 
according to Submitter name?

I just tried to have a quick scan of all my contributions to the 
R3 bugs (see discussion in REBOL3 group).
It was not easy.

I'd especially like an easy way to find FIXed bugs by submitter name......That'd 
remind and encourage me to test the ones I'd raised.

will sorting work? they don't work for me in Safari

Sorting: it works with the "Search" and "Detail" filters but not 
with the "Preset" ones. That's an intended feature. I've just tested 
with Chrome 2.0 and sorting works as expected (should be the same 
for Safari, no?).

or simply have sorting working under Presets. then no need for UI 
tweaks.

Changelog : 0.9.8 - 26/05/2009

	o FEAT: "User" column added to tickets list page.
	o FEAT: Search text feature extended to comments.
	o FEAT: "Main" page now populated with statistics.
	o FEAT: New Preset filter: "My Reports" (default when logged)
	
	o FIX:  "By Submitter" filter now working correctly.
	o FIX:  Redirection issues with Chrome fixed.
	o FIX:  In Preset mode, columns sorting links removed.
	
	o LOOK: Textarea edit fields now enlarged to maximum width.