AltME groups: search

I remember there being a spreadsheet expression evaluator that made 
it a point to have a small enough number of operations in its bytecode 
that it could fit two operations per byte. That means that with cache 
issues taken into account, its code was drastically faster than fully 
compiled code. The interpreter fit entirely in the instruction cache 
of a 486, and the bytecode was much smaller than regular native instructions, 
so the bytecode could be pushed into the CPU faster. This kind of 
a thing is even more of an issue now, with CPUs that are many times 
more faster than the memory busses, and even bigger caches.

Using the comlib allows you to access indivdual cells in an Excel 
spreadsheet

I want to be able to read cells data from EXCEL.  Could I do that 
with COM?  I can't find a way to automate the conversion of excel 
spreadsheets to tab deliminated format so I think I gotta work directly 
with the spreadsheet data.  Which sucks.

IT would be cool if it had an output that was flat text (not REBOL), 
this way we can through it in a spreadsheet quickly, and over time, 
paint a picture of how people program... (size matters, but relative 
usage of REBOL is of greater interest to me).

I don't get a menu on top of the spreadsheet window

work on it for a couple of more weeks and you'd have a spreadsheet 
that would be fully usable. this is so impressive.

go for a quantrix style spreadsheet

Steve, here you can download my contribution to the Spreadsheet Contest:
http://www.rebol.cz/~cyphre/cyphres.sht
(hope I win :-))

eFishAnt, where is this spreadsheet contest described?

Maxim: Spreadsheet  and/or Announce....just make a spreadsheet for 
nano-sheets.r from article, and winner gets $50 prize.

I want to create a little spreadsheet application where users have 
access to the mathematical functions in rebol and nothing else.

Seems I have enough clues now to write my little spreadsheet :)

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.

When writing a spreadsheet/grid, is it better to give each cell a 
name, or work out the location based on  a grid reference?

Anton,  What do you think of this approach -- I'm just thinking it 
through and am not sure if I have covered all the bases.

Since my input can contain any number of symbols, commas, single 
and double quotes, and rarely, but possibly braces, what if I attack 
the problem a different way.  Whenever an embedded comma, or double 
quote or something like that occurs within an spreadsheet cell, it 
will require some kind of "extra" formatting like two quotes or the 
like.  It may even be that there are unique combinations of such 
symbols, rare as that would be, to have complex formatting of an 
input block for rebol to convert it properly for CSV.


What if I shift gears and look at a TAB delimited file instead.  
I know that I will never have TAB embedded in my cells, and that 
I deal with the entire block as a series instead.  I could embed 
TAB wherever needed to separate the columns and leave the remaining 
string the way it is.  Would that work, or would I still need to 
do some formatting to handle it.  I think I'll open an excel spreadsheet, 
and work in reverse to see what it needs for TAB delimited file. 
 Any comments?

My end goal is to be able to take some formatted text of some kind, 
something that is generated by a utility of some kind, and generate 
a spreadsheet from it.  The formatted text can be of any type including 
" and the like.


I'm working in reverse, by creating a spreadsheet in MS excel with 
various kinds of data that I've shown above.  Some data with just 
alpha, just numbers, combinatins, leading quotes, trailing quotes, 
embedded quotes, embedded commas, spaces etc.  Then I saved the spreadsheet 
as CSV and another version as Tab delimited.


Then by looking at those files via notepad or other editor, I can 
see how the data must be in order for MS excel to accept it.  I initially 
had problems with the CSV model because embedded qutoes needs other 
qutoes added to that "cell" if you will.  The Tab delimited model 
has less restrictions on it.  The only thing that needs attention 
is when a "cell" starts with a quote, which needs additional quotes 
added to it.  Embedded qutoes or trailing qutoes don't need any modification.


Long story short -- I'm going with Tab delimited model and figuring 
out a rebol script to take data from an IBM utility dump (with rules 
on what data to capture), and model that info into an excel spreadsheet 
via Tab delimited file.

Hi Gregg -- The cookbook recipe is a good one for reading and processing 
CSV's as input.  My main issue is NOT the CSV part itself.  It is 
pretty simple really.  But as usual MS has some additional formatting 
rules whenever certain characters are embedded, and that is the part 
I'm having trouble with in order for a CSV file to be loaded as a 
spreadsheet. 


You don't happen to have one that lets you write CSV files as output 
for excel (with all the special rules etc)???   :-)

Hi Henrik!


the "" hold the place, so that my cells no longer shift over, but 
that value gets displayed in my output as a pair of double quotes, 
when I'd prefer to see a blank.  This output is headed to an Excel 
spreadsheet, for what that's worth.

50mb and includes.. 


XMMS (MP3, CD Music, and MPEG), FTP client, Dillo web browser, links 
web browser, FireFox, spreadsheet, Sylpheed email, spellcheck (US 
English), a word-processor (FLwriter), three editors (Beaver, Vim, 
and Nano [Pico clone]), graphics editing and viewing (Xpaint, and 
xzgv), Xpdf (PDF Viewer), emelFM (file manager), Naim (AIM, ICQ, 
IRC), VNCviwer, Rdesktop, SSH/SCP server and client, DHCP client, 
PPP, PPPoE (ADSL), a web server, calculator, generic and GhostScript 
printer support, NFS, Fluxbox window manager, games, system monitoring 
apps, a host of command line tools, USB support, and pcmcia support, 
some wireless support.

Announcement:  eFishAntSea is offering a $50 contest prize to the 
top spreadsheet someone can create with rebocalc.r.  eFishAntSea 
will judge the entries, acknowledge the author in an article (if 
the article is accepted, of course).  Please submit privately to 
Steve Shireman, preferably by X Internet.

entries due by Feb 20, 2005...for spreadsheet contest.

questions, info...see Spreadsheet group...thanks.

eFishAntSea has extended the Spreadsheet contest for the best showcase 
spreadsheet which

 nano-sheets can run.  Contest entries will be judged by eFishAntSea 
 and the selected winner's spreadsheet will be added to next month's 
 devX article (assuming they publish it) and a cash prize of $50.00 
 and the link to nano-sheets is ... http://www.efishantsea.com/nano-sheets.zip

http://www.practicalproductivity.com/files/xls2txt.xls- excel macro 
I made to convert excel spreadsheet into tab delimitted text. Pretty 
handy!

Latest build available at: http://www.dobeash.com/files/RebGUI-022.zip

Highlights include:

	- Added drop-list, edit-list and auto-fill widgets
	- New splash function added (run %tour.r to see it in action)

 - Window management logic improved (disallows duplicate windows and 
 "sticks" child windows to first)
	- Couple of minor fixes and cosmetic improvements
	- %tour.r has an additional "List" tab

 - Prototype table widget added (run %table-002.r to see it in action)

Known issues

	- spinner and auto-fill widgets need more work
	- edit-feel needs to handle highlight, cut & paste
	- scroller needs more work (resizeable dragger)
	- table needs row selection logic added
	- edit-list needs auto-fill logic added

In progress

	- Improved tab-panel
	- Menu
	- tabbing
	- field input validation (field input masks, etc)
	- list-view (shadwolf)


With regards to "lists", I envision 5 types we need. They are (in 
ascending order of complexity):


 drop-list	- non-editable, single sorted column with single value 
 selection [optimized for < 100 values]

 edit-list	- derived from drop-list but editable with an auto-fill 
 field

 table		- multi-column representation of a DB table; used to create 
 something like a GUI SQL client with single-row selection [< 100,000 
 rows]

 list-view	- multi-column multi-media content (supports images, URL's, 
 etc); used to create something like a file explorer with single perhaps 
 multi-row selection [<10,000 rows]

 grid		- cell-level addressing and editing supporting simple spreadsheet 
 formulas and formatting [< 1,000 rows]

I'm using code like the following quite often now:

	display join settings/file " Summary" compose/only [
		...

  records: table 90x25 #W options ["Date" right .4 "User" left .2 "Description" 
  left .4] data (

   sql compose [select [date user description] from sys_records where 
   (id) order by date desc]
		) [
			;	set record path
			record-path: dirize join file-path first face/selected
			...
		]
	...
	]


The table widget is now very DB friendly. I haven't had a need for 
a grid widget, but then again my apps don't require spreadsheet type 
functionality.

Will a REBOL spreadsheet script help you? http://www.devx.com/opensource/Article/27454/0

Had a look at porting Henrik's list-view over to RebGUI. Main challenge 
would be to convert / merge 4 styles (list-icon, list-field, list-text 
and list-view) into a single rebface. This would require quite a 
bit of code restructing. The actual internals don't need too much 
work (functions and feel code are pretty VID/RebGUI neutral), but 
a lot of references to RebGUI 'standards' need to be added; such 
as:

	default-* objects instead of system objects
	ctx-rebgui/sizes
	ctx-rebgui/colors


And the span facet needs to be added (and support logic added) to 
enable dynamic resize / rescale. Given the amount of code that needs 
to be changed, I don't believe a VID and RebGUI version can be [easily] 
built from the same code-base (i.e. the port will in effect create 
a fork).


Also, from a code complexity POV, the list-view widget is almost 
as large as *all other widgets combined* ... and it includes functionality 
that could probably otherwise go into a grid / spreadsheet type widget 
(list-view is almost a GUI framework in its own right now! ;)). If 
anyone's in doubt, I think Henrik's work rocks and fills a much needed 
gap in VID functionality. ;)

At what "size" of array do you notice slow downs?  We are about to 
add a simple spreadsheet to Qtask.  We will be facing the same issues. 
 In our case we will be using Javascript on the front end, but the 
issues are similar, we have to decide which parts work on the client 
(virtual as you would say), or when we do a complete refresh.

I didn't show the spreadsheet screen shot.  I noticed it had some 
real $ amounts shown.

Uploaded build#108.

1) Fixed UI quirks with tree widget

2) Renamed vid widget to style

3) Added a new scroll-panel widget

	USAGE:
		scroll-panel data [calendar]
		scroll-panel data [field field]

	DESCRIPTION:
		A panel used to group widgets within a scrollable container.

4) Added a new sheet widget

	USAGE:
		sheet
		sheet options [size 3x3 width 2]
		sheet data [A1 1 A2 2 A3 "=A1 + A2"]

	DESCRIPTION:

  Simple spreadsheet, based on rebocalc.r, with formulas calculated 
  left to right, top to bottom.

  A cell is either a scalar value, string, or a formula starting with 
  "=".

  Scalar values are automatically right-justified, series values left-justified.

  Remember to put spaces between each item in a formula and use () 
  where needed.

	OPTIONS:
		'size specifies number of columns and rows
		'width specifies cell width in relation to cell height


5) Updated %tour.r to incorporate examples of tree (List), scroll-panel 
(Grouping) and sheet (List) usage.

Enjoy!

Yep, a lot of that code is app / context specific; although the widget 
should allow you to extend its functionality via APIs rather than 
having to "roll your own" every time you need a bit of extra functionality. 
scroll-panel is a move in that direction; "I'd like a spreadsheet 
here, and I'll put that in a scroll-panel because I want to scroll 
a large sheet; and I'll add left-click and right-click handlers to 
handle load and save; and assign a screen dump routine to F3, etc". 
All that is currently possible. "I'd like to move this cell from 
here to here" is not currently possible, and I doubt anyone could 
create an API that could let you do *everything*. (take something 
simple like alternating row colors; I had someone ask if the *number* 
of alternating colors could also be specified!)

There is the spreadsheet thingy which is a grid.

Ashley, would be feasible to enhance the spreadsheet to allow user 
defined column widths? ( in the options block )

>> google-xml: load-xml/dom clipboard:// ; copied from page
>> entries: google-xml/get-by-tag <entry>
== [make object! [
        name: <entry>
        space: none
        value: [
            #etag {"BxAUSh5RAyp7ImBq"} 
            <...
>> foreach entry entries [probe entry/get <resourceId>]
spreadsheet:key
== "spreadsheet:key"

2 Mac mini (PPC) with 23" Cinema displays plus an iBook with Parallels 
running WinXP. The whole lot is networked via AIrport Express to 
an ADSL modem and a Brother MFC-8840D. I've had no problems and zero 
downtime for over two years. I switched from Windows/Linux about 
two years ago and haven't looked back. Some of the business advantages 
include:

	- Almost silent operation
	- Low power consumption
	- Small footprint
	- Zero admin
	- The WOW! factor when clients see your setup
	- Cheap
	- Out-of-the-box solution (no extra s/w required)


In fact, the only software I have purchased is iWorks and .Mac membership. 
The one issue I have is with Spreadsheets on the Mac minis. I don't 
want to use/pay for MS*Office and iWorks does not have a spreadsheet, 
so I'm using NeoOffice (aka OpenOffice) which is SLOWWWWW on PPC 
hardware. Works well on the (Intel) iBook though. I'll upgrade the 
Mac minis to Intel when Apple refreshes the line (probably when they 
release Leopard later this year).


Parallels is a must if, like me, you have to run or support legacy 
software running on Windows. Coherence mode puts the Windows task 
bar directly on the Mac OSX desktop and enables you to run Windows 
programs directly from it. It's hardware virtualization so it's fast, 
and removes the need for multiple machines. The ability to cut&paste 
directly from a Mac app to a Windows one is also pretty handy.


Bottom line is, if you like to play and endlessly tinker with stuff 
then WIndows/Linux is the way to go; if you want a tool that just 
works then get a Mac.

Ashley, can you explain in a little more detail how your setup works 
for you?

 Sure. I run a home office with two studies. Each has a Mac mini (plus 
 Cinema display) for day-to-day work. My study also has a TabletPC 
 connected to a 1280x1024 VGA LCD display. I use this for REBOL development 
 and demos away from home.


The iBook is located in the other study and is used by my better 
half when running Windows software related to our finance company 
(CRM/Sales software distributed via the professional body we belong 
to, no Mac or Linux option available). We also use the iBook when 
showing non-IT people stuff (e.g. a spreadsheet showing how much 
their portfolio could be worth if they geared it) and when attending 
training sessions.


The ADSL modem has an ethernet connection to Airport express, which 
in turn has the MFC plugged into its USB slot. The Mac's pick up 
the printer automatically, the TabletPC runs Bonjour and does the 
same. Everything, including the TabletPC, detected the Network without 
issue. It really has been as simple as, 1) Unpack, 2) Plug-in, 3) 
Use. I've also noticed that WinXP running on the iBook is a lot faster/smoother 
than on the TabletPC as it installs 'clean' (i.e. piggy-backs off 
the Mac's Network and Hardware support).


Large screens are a must if you write and or read a lot of documents. 
A 1920x1200 screen lets you do a slideshow on a PDF document and 
read the pages side-by-side. On wide screens I always have the task-bar/dock 
on the right to maximize the vertical display area.

Thank you Sunanda -- I will give that a try.


Just to let you know -- My goal is to convert a printable report 
that is in a file into a spreadsheet.
Some fields will only appear once per page like PAGE.

Some fields could appear in a new section of the page multiple times 
like NAME in my example.
And some fields could appear many times per section like MEMBER:
_______________________
Page header          PAGE     1
Section header     NAME1.1
Detail lines            MEMBER1.1.1
Detail lines            MEMBER1.1.2
Section header     NAME1.2
Detail lines            MEMBER1.2.1
Detail lines            MEMBER1.2.2
Page header         PAGE    2
(repeat of above)____________


I want to create a spreadsheet that takes different capturable fields 
and place them on the same line as the detail lines like so...
______________________
Page   Name       Member
1          NAME1.1  MEMBER1.1.1
1          NAME1.1  MEMBER1.1.2
1          NAME1.2  MEMBER1.2.1
1          NAME1.2  MEMBER1.2.2

2          NAME2.1  MEMBER2.1.1  ...    (the version numbers are 
simply a way to relay which captured field I am referring to (Page, 
Name, Member)


Anyway -- that is my goal.  I have figured out how to do the looping, 
and can identify the record types, but you are right about the possiblity 
of mis-identifying lines.

I don't say, you should use a REBOL substitude for Excel. You have 
other options! OpenOffice has an excellent spreadsheet. I would guess, 
KOffice and other office packages has too. Why not switch to one 
of those and then integrate with them using REBOL?

Robert, on a recent project my app creates an xml file formatted 
with xml that Excel understands. It's a hassle but you can make very 
pretty spreadsheets that do just about all the formatting (so it's 
a far cry from CSV). I start with creatinga very small excel spreadsheet 
then saving as an xml file. Then I check out how they do the formatting. 
You can create multiple tabbed spreadsheets very easily this way. 
Doesn't do graphs though.

it'd be cool to build a group based spreadsheet that takes advantage 
of AltME filesharing.

First off, I haven't used a spreadsheet in 10 years, and second.. 
wetpaint.com generates a boring web 1.0 page  (here's the wetpaint 
anime page http://anime.wetpaint.com/
C'mon people.. think out of the box.

Google acquired JotSpot

http://www.jot.com/


hmm.. with Calendar, Spreadsheet, etc...they may turn it into a Project 
Management thing.

I've been hearing that, Reichart, for at least 30 years.

It remains as partially true as it ever was -- like we ned very few 
people to write spreadsheet programs, while zillions have been enabled 
to write spreadsheets. But it's hardly a self-evident conclusion 
for (say) someone considering a new career

I would like it, but it would have to be done right. We'd need to 
make:

- A kick ass text renderer/type setter
- A kick ass spreadsheet cell renderer
- A kick ass drawing program


The rest kicks ass already, and will even more so when R3 comes out. 
When those components would be done, you build the UI around that.

just conjoin results as CSV and show them in spreadsheet..

conjoin inserts delemiters too, did i get that right? How about a 
simple 'list, i feel its a good match, listing things. But not native 
speaker.. Another idea: it icould be related to csv (this spreadsheet-format, 
got i the letters right), a conjoin is close to exporting?

Henrik: Cool stuff so far. But, aren't you the guy doing the list-view 
stuff?


I think the current VID should really be stressed on a complex real-world 
example: A Table/Spreadsheet that can handle 1 Mio. rows with high 
speed a la Excel. It's a widget type you can use to show stuff or 
even let people enter something.

Lazy: Let's assume I have a quite complex evaluation graph with 100 
input parameters. Think of it like an Excel spreadsheet. Now what 
I want is that if one parameter changes, that all dependent parts 
are re-evaluated. Like Excel does it.

robert, If I start from scratch, it will be an n dimension spreadsheet 
with a scale of infinity in each of those dimensions (thus really 
limited by RAM, disk and REBOL types).   why start it up with a limitiation 
which is actually very easy to design correctly for starters... 


especially with GLayout which would just adjust the views as they 
grow.

Max, would your engine be good fit for a spreadsheet calculation 
engine? Steve Shireman wrote this nice tiny spreadsheet widget (http://www.efishantsea.com/nano-sheets.zip), 
I guess that pluging liquid inside would make a killer demo both 
for liquid and REBOL, don't you think so?

Steeve, that would defeat the purpose of buying a large screen so 
you can see more stuff. Used a spreadsheet lately? Graham, that can 
change the whole layout. If it autoadjusts, cool, but you'd at least 
need different layouts for languages that go in different directions.

On naming, I think PANEL is too general and doesn't describe the 
layout behavior. I could live with it though. 


I agree that TABLE should be saved as that is the common term for 
the spreadsheet model. GRID was used for that for a long time, and 
still is sometimes, but GRID could also be good when thought of as 
a canonical grid layout. GRID-LAY, CANON-LAY, or TABLET aren't too 
inspiring either.

Yes, I see that point as well. Most of time I resize something it 
is to either gain more real estate (Obviously shrinking the window) 
or to see what is being hidden, as with a large spreadsheet or to 
show me more as one might do with an email client.  In the latter 
case, the objects resize larger but not the fonts, etc. This ALTME 
window is a good example. If I want to see more messages I can increase 
the size but I don't expect everything to just get bigger.

GrahamC, thank you for passing this around.  I did get part way to 
a solution, as noted on your site.  Strange as it may seem, I am 
able to get to the network drives if I run a copy of REBOL that I 
download and leave with the name it came with, namely rebol-view-278-3-1. 
 The copy of REBOL that was giving me trouble was the same rebol-view-278-3-1, 
but I had renamed it to rebview to make a desktop shortcut work. 
 I had the name "rebview" in the shortcut so that I would not have 
to change the shortcut if I ever got an upgraded version of REBOL 
with a different name, like maybe rebol-view-279.  So my first problem 
with WIndows 7, REBOL, and network drives seems fixed.  


I still am not to a full solution to my Windows 7 issues.  I have 
some REBOL scripts that use the "call" command to run powershell. 
 Powershell then runs a powershell script to extract stuff from an 
EXCEL spreadsheet, which then is manipulated by the REBOL script. 
 Actually it's a bit messier.  I run a REBOL program launcher on 
the C drive which runs a REBOL script on a network drive.  The script 
on the network drive calls powershell with parameters to make powershell 
run a powershell script.  The powershell script extracts EXCEL data, 
and the calling REBOL script then makes a report of the extracted 
data.  


When I try to do this, the result from powershell is that I am not 
allowed to run scripts on that computer.  I am aware of this feature 
of powershell, and I have done what has worked for Windows XP (set-executionpolicy 
remotesigned).  I can run powershell directly, and execute scripts 
located on a network drive.  When a REBOL script that worked on XP 
calls powershell on WIndows 7, it won't go.  I am not expecting any 
help with this last issue at this time because the "call" does work 
in some cases (call/shell "notepad") (call/console/show "powershell"), 
so I still have several things to try, and if none work I am plotting 
a work-around.

REBOL code is interpreted, but not its source. The slow part of a 
source interpreter is parsing the source into the intermediate code, 
the AST. REBOL is an AST evaluator. The advantage to that relative 
to a bytecode VM is that you can extend the runtime with more fast 
operations without breaking the bytecode encoding, but the disadvantage 
is that the interpreter overhead is larger so if you want your operations 
to be efficient you have to use larger ones. This is why C-like code 
is slow in REBOL, but high-level code can be fast.


If you want to get the advantages of a bytecode VM with the extensibility 
advantages of REBOL's model you could go with an address-threaded 
interpreter. Address-threaded interpreters have more data going through 
the processor than bytecode interpreters do, but it you need to support 
higher-level operations they are more efficient overall. However, 
if you don't need to support higher-level operations and only need 
to support a tiny number of low-level operations then bytecode can 
be encoded in a much smaller amount of space. If your language is, 
for instance, a spreadsheet formula evaluator then you might even 
be able to have 4-bit bytecodes, with two operations per byte, and 
have an interpreter that fits entirely in the instruction cache of 
a processor. Bytecodes can be much faster then.


Still, Lua's bytecode VM, as efficient as it is, has been running 
into performance limits as well. Fortunately, a bytecode model that 
maps well enough to the native code model (remember what I said earlier 
about C-like bytecode VMs?) can have the bytecodes translated to 
native code at runtime and then execute the native code. For C-like 
code that is usually even faster than address-threading. This is 
why LuaJIT has been doing so well when compared to Lua's bytecode 
VM.


World being Lua-like means that it can improve using methods similar 
to the ones that Lua has been using to improve. That's definitely 
a good thing, since it means that Geomol doesn't have to work from 
scratch :)