AltME groups: search

Diffs. I mean load the current base from the repository and generata 
a universal patch using the diff cmd on the two copies. Then we can 
check changes one by one.

(easy enough fix: http://gitorious.org/~earl/boron/earl-boron/commit/73e33bd.diff)

I believe the PE file format has sections that are padded, so it 
may be that the internal padding is different, as are the code segments, 
but the resulting EXE is the same size. I suppose you could do a 
binary diff to see.

G: no diff, just license key.

like this?
the cli connector is using the cli component nearly all major
databases delivering. the connection is made via rebols 

call/wait/info/output/error and a simple parse after, for the resultset.
I am using this prototype mainly for a q & d connect

to mysql/postgresql/monetdb/sqlite. on my list are also connectors 
for

firebird/oracle/greenplum/sybase/ingres/infobright/frontbase and 
cassandra.
pros:

1. very fast for single requests
2. no rewrite of code needed if a new version or protocol is out
3. easy 'data migration' between the db's

4. adding new db's are a matter of hours only (see the cli spec thats 
all)
5. fast prototyping and testing for new db's

6. robust, never had any trouble with cli's even with bigger resultsets

7. should be perfect also for traditional cgi (the process starting 
overhead is minimal, execpt you name is facebook)

8. very small footprint (~120 lines for connecting to 4 db's, could 
be the half)

with a nice tcp-server component like rebservice the 
cli multi connector could be very usefull as a c/s connector.
I made a test with 2.000 concurrent calls (simple select) 
on a 4 gig quadcore. the cpu was only close to 50%, a good value.

cons:


1. slow if you have very much serial inserts (unless you shape them 
into one sql query)
2. need to start a cli process for every request
3. needs a tcp server for non-local connections
4. some more, but who cares ;-)

with a solution to keep the cli open from rebservice,

these cons could disappear and the speed diff overhead to a memory 
based lib
could be marginal.

Robert - I can't work with RMA team by writing code etc. My primary 
job makes me come home between 18:00 - 20:00, then I have another 
company where we run 700+ wifi users, some other projects. I am not 
complaining, I like it :-) It is just that a) little of free time 
remains b) you would not want my "code" to oficially accept :-)


But - I don't necessarily be the one, who just talks. Give me something 
specific to test. I think I now will find my way with Henrik/Rebolek 
on my own. It is just the current release format (flattened source) 
is a bit uncomfort to study code segmentation and separation, and 
- difficult to know what changed, if there's no changelog. (I know 
I could use diff on 256kb source, but ....)


So - I think I will let it as it is - it is enough if e.g. Rebolek 
says just few words for the release - e.g. - please test new tab 
... and I can look at it, and givi it a run ...

they might know how to store things in diff mode, but only it can 
know based on current state, when its remembering.

also, there is a tricky thing to redoing in that its often more like 
a complement than an inverse of an undo... especially when storing 
diff data.

New http://94.145.78.91/files/r3/gui/r3-gui-src.zip


This one seems not to be as stable with the tests, and the style 
browser won't run, but offering it anyway.

The old version from 24-dec-2010 for diff is available at:

http://94.145.78.91/files/r3/gui/r3-gui-src-002.zip

It makes sense... because I could save some time if I could work 
with your version or to be able make a diff between Carl's and yours.

(And if you diff A107 Linux against the Win32 version, you'll see 
the base for my "Lazyness" comment.)

Andreas, can I diff against 107 to find out which vectors I'm missing 
and where to put them?

A: The OS/dirs are for code that is really quite different.  Merging 
into a single source does not help keep it in sync, because most 
coders only modify the platform of their choice. They can just as 
easily diff.

Diff your own releases and you will see.

Here's the diff of host-lib.h in between Win32 A107 and Linux A107:
https://gist.github.com/353ad14fedab30dddd83

There's something wrong with that diff... where did you get Linux 
A107 host-kit?

There's nothing wrong with that diff, it's been that way since A102. 
And it still is that way in A109.

But don't take my word for it, diff the downloads you provide on 
your site.

Has anybody built a binary diff/patch function set?

If I want to store some fairly big data as undo information, it seems 
to make sense to store it as a diff, and load the data that I want 
to undo/redo to. Then it would also be possible to store the entire 
changes sequence to disk.

binary diff can be expensive - if you control the application that 
modifies the data, can you log the changes instead?

The biggest object here is around 4 MB or 550 kb compressed. I expect 
that binary diff would only be used during load and save, and then 
keep full objects in memory.

A "git diff --cache" will then show you the changes compared to the 
last commit.

git diff emits patches

Not sure what you've mentioned, but here is my config output:

core.symlinks=false
core.autocrlf=true
color.diff=auto
pack.packsizelimit=2g
help.format=html
http.sslcainfo=/bin/curl-ca-bundle.crt
sendemail.smtpserver=/bin/msmtp.exe
user.name=
user.email=
core.autocrlf=true
core.safecrlf=false

done.. you can find complete diff for the pull request here: https://github.com/dockimbel/Red/pull/201/files