-
Notifications
You must be signed in to change notification settings - Fork 3
/
Copy pathDEVLOG.txt
2496 lines (1858 loc) · 87.3 KB
/
DEVLOG.txt
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783
784
785
786
787
788
789
790
791
792
793
794
795
796
797
798
799
800
801
802
803
804
805
806
807
808
809
810
811
812
813
814
815
816
817
818
819
820
821
822
823
824
825
826
827
828
829
830
831
832
833
834
835
836
837
838
839
840
841
842
843
844
845
846
847
848
849
850
851
852
853
854
855
856
857
858
859
860
861
862
863
864
865
866
867
868
869
870
871
872
873
874
875
876
877
878
879
880
881
882
883
884
885
886
887
888
889
890
891
892
893
894
895
896
897
898
899
900
901
902
903
904
905
906
907
908
909
910
911
912
913
914
915
916
917
918
919
920
921
922
923
924
925
926
927
928
929
930
931
932
933
934
935
936
937
938
939
940
941
942
943
944
945
946
947
948
949
950
951
952
953
954
955
956
957
958
959
960
961
962
963
964
965
966
967
968
969
970
971
972
973
974
975
976
977
978
979
980
981
982
983
984
985
986
987
988
989
990
991
992
993
994
995
996
997
998
999
1000
================================================================================
A file for day-to-day development issues
================================================================================
General Notes:
----------------------------------------
How to load from source without using the scripts in bin/:
I depend on shell scripts for launching the compiler so often that
it's easy to forget what to call to load the code directly in one of
the scheme systems. Here's a quick reference.
You can always start up a repl in the src/ directory and do "(import (main))" by hand.
echo '#!r6rs' > imports_only.sls
echo "(import (except (rnrs (6)) error) (main_r6rs) (main) (ws shortcuts))" >> imports_only.sls
chez imports_only.sls
PLTCOLLECTS=$PLTCOLLECTS:$REGIMENTD/src mzscheme imports_only.sls
================================================================================
[2004.04.29]
Hmm, without "identifier-syntax" I can't get things working fully
under PLT. Until I can write a "lazy-letrec" macro for PLT I'm not
going to be able to have testing in drscheme. Sigh. Ok, for the
moment I'm just going to focus on the chez code.
[2004.05.21]
WEIRD. Chez scheme started up with the normal heap is hanging on
(define-record a (b c)). What is wrong with my system right now??
[2004.05.26]
Right now I'm trying to hack the final Sim_nought together.
Annoying model/view issues without object system. It's gonna be work
to get the plt version working.
[2004.05.27]
15:30: There! Dammit, the basic simulator works in swl. Now gotta
get an actual meaningful display of it up.
17:30: Yay! Ok, for the first time runnning a little token-machine
with graphics!
[2004.06.09] {How to return values?}
9:47am: Ok, I'm trying to tie together the compiler and the
graphical simulator. Right now I'm trying to figure out how
*returning values* should work. Especially since almost all the
return values will be streams.
8:05pm: I'm all screwed up now wrt the status of local bindings for
token handlers. I'm trying to make my token-language a little wider
than it needs to be for my compiler, that makes it easier for me to
make test-cases by hand.
[2004.06.10]
Need to think about what happens when two processes are using
gradients when the same token name, and they start hitting eachother!
Sonuds like a big problem, how did that not occur to me before.
[2004.06.13]
It's annoying to add more complexity like this. But I'm adding an
(ONLYPLT <expr>*) and possibly ONLYCHEZ syntax to my code in the
generic/ branch. SCRATCH THAT. Not doing it yet. Might do it soon
tho, it's not that unreasonably an idea.
[2004.06.16]
Dammit I got burned again by a recompilation failure on
graphics_stub.zo. PLTs system for time-stamp checks on compiled files
is totally broken... Or maybe my clock skew is all to blame.
Overall my ratio of messing with my environment vs. making progress
has been horrible, and this isn't entirely my fault. My environment
has big problems. Sigh, I should have used a safer language, I don't
think I'm really getting enough benifits from scheme... but it's too
late to back out now. Eventually it will be a haskell compiler, so
theoretically I can dump this compiler as soon as I'm done with my
masters.
Although, even given my decisions thusfar, it was a bad idea to make
a simulator at all.. I *totally* should have just hacked onward
towards NesC. Sigh.
1:33pm: *THere* all the damn graphical simulator tests work in PLT
also..
[2004.06.17]
URGH. Having problems returning a stream of answers. Can't nest
engines dammit! So run-flat-threads is not a sufficient interface...
Hmmm strange bug right now, trying to get my stream-outputting
simulator to work. It'll run for a while and then get an invalid
application for soc-return. How does it suddenly come out of that
fluid-let? What's with that?
[2004.07.07]
Ok, need to drive to finish up a demo for tomorrow. I don't have
*returns* working right. That's the priority for right this second.
Making a big fat complex test in the test-suite for simulator_nought.ss.
Got test suite up for simulator_nought with the return-test. Now for
a bigger test that actual returns some values!
*) Rudimentary heartbeat
*) Time and widen the aggregation-window...
[2004.07.13]
Ok, gonna do a refactoring to lift out a "build-call" within simulator_nought.
TODO: Fix unit-tester so that it won't give the special 'error value
to the oracle!!!
[2004.07.27] Trying to finish return values
Ok, I was going to add a time-window for the return values, but
right now I'm deciding between that and an explicit generation
counter. But how would I know whether I've gotten everything in
the generation? Could use a safely large time-window and seperate
out the different generations within it?
[2004.07.30] {Tokens first class and skeleton pushing}
Ok, going to make token-names *first class values*. Reason is, that
map is going to dynamically pass along the name of the token that
provides the skeleton for the map. I could do this with a static
analysis, but that makes me even less scalable to more general
language features.
ACTUALLY, I take it back, I may do that in the future, but right now
I'm just going to introduce a simple propogate-skeletons pass which
annotates folds appropriately.
I still need to make tokens first class at somepoint... right now I'm
being inconsistent with them. I should also right down a type-system
and some semantics for the token machines. (Also need to think about
Matt's modifications...)
Sigh, right now I'm throwing a bunch of hackery into deglobalize that
should probably properly belong in other passes. This is bad form.
But some of these things are so experimental and temporary, that
setting up extra passes for them seems not worth it...
[2004.08.03] {About the cost model that I'd like to have}
Thinking about metrics used in that Bill Theis "Linear Analysis" paper...
Wait, wait, first a bit of meta-reasoning, the cost model must be
either:
*) Context free, parts of the program are assigned a cost w/out
regard to their context
*) Context sensitive - a much trickier computation, probably using
existing program analysis techniques.
Well let's first think about reasoning over all connection topologies.
[2004.08.06]
Reading about TinyOS. I like how you can wire outwires to multiple
components. Like hooking Main.StdControl to multiple targets. But
what are the semantics for which of these calls comes first? In the
order you list the edges??
[2004.08.11]
I need to sort things out... I'd like all areas to take a single
argument carrying their value.. but regions must be otherwise. "this"
isn't going to be first class in the token-machine abstraction, so
it's not viable for Regions to pass "this" as the token argument.
Problem is when you're generating code for "filter" you don't know
off the bat whether it's running against a Region, or some other Area.
We can always just pass null, or the node id as the value carried for
region membership...
[2004.08.15]
Ok I'm working on places and routing now. Maybe next I need pull/push
and/or known/unknown annotations. I really like doing more of the
work before deglobalize.
[2004.08.16]
Ok, I'm digging into TinyOS a bit more now. I've used it
embarassingly little. Notes...
Data segment of a message is fixed to 29 bytes. Don't put more than
that in it!
TOSH_DATA_LENGTH
TOS_LOCAL_ADDRESS = our local address
[2004.08.20]
So that TOS_Msg struct definition is in AM.h
[2004.09.07]
WHOA! If I have a BareSendMsg interface (wired to UARTNoCRC...), when
I send the message it *also* fires the sendDone event from this
*other* SendMsg component I have!??! I guess it's just determined by
the message type, and doesn't give a damn about the static component
bindings and whether or not you sent with the corresponding send method....
But I still can't get a message sent with a BareSendMsg interface...
[2004.09.29]
There's some serious lack of clarity in my head right now as to what
the abstraction boundary should be between the generated NesC code and
the static NesC runtime. As much as possible should be factored over
to the runtime side. But the generated code needs to provide the
actual handler for tokens. Although that can just be *one* function.
m
WAIT: stupid question, but TinyOs does make a seperate instantiation
for each use of each module? Or are all timers the same timer!?
[2004.10.17]
I finished my brief return to messing with the front-end. Looking at
this NesC code again. I see the FIFO I set up is working correctly
now.
[2004.10.21]
Gonna switch it so no prims take LISTS..
[2004.10.24]
Sigh, right now I'm hacking on the simulator, trying to get it back up
to speed... Doing some cleanup and documentation in the process.
Adding "reject". It has a pretty yucky semantics at the minute. I
need to simplify simplify... It's inclusion presently is yet another
quick and nasty hack.
[2004.11.04]
The component model is tricky... you need to remember to get
StdControl to things. I still have very embarassing
non-understandings of the way things work.
I need to understand the memory management a lot better. I don't know
when it's safe for me to give a pointer to a send or receive, because
I don't want the memory to be corrupted while something else still
needs it. For example what on earth happens if I send a pointer to a
local variable to SendMsg.send??
[2004.11.05]
Ok, making a relatively big change here. I've got the tokenhandlers
just working right off the message (token), figuring that the token is already
allocated, and they can use that. This is a bad assumption, because
sometimes it isn't... and allocating an extra whole TOS_Msg is horrible.
Right now I have really broken buffer management, I need to get some
locks on things and try to make sense of stuff.
[2004.11.08]
I have had some seriously bad experience using the tossim simulator.
It will hang, I don't always think the gui display is saying the right
thing, etc...
[2004.12.01]
Ok, trying to get back into it for a final run of (pre-masters)
hacking.
Grr.. trying to run drscheme on jetta still gets the symbol error with
__libc_stack_end from ld-linux.so.2 (GLIBC 2). Sigh.
Could try hacking in my own version and using ldconfig...
[2004.12.05]
Wow, Mondrian had support for dynamic specialization stuff?
[2004.12.06]
Messing around with the simulator and GUI, there's some severe
timing-dependency problems there. I can do a simulation at 20 nodes
and have things basically work, but then not work at 100 nodes.
Man if I actually get anyone else to work on this with me maybe the
right thing to do for the second version would be to do it in Java or
something (with a C-like external rep for Token Machines).
[2005.01.13]
Thusfar the NesC component system has just got in my way and annoyed me.
[2006.02.28] {Looking at poor SWL stability}
Trying to remember exactly what it is that causes the SWL invalid
command name problem.
Right now I'm having a lot of nondeterminism / timing-dependency
problems with SWL. The unit tests will crash if run normally.
Sometimes it will crash around test 9 with an obscure error. However,
if I run unit tests one at a time, manually, I haven't yet found one
that doesn't pass.
Further, this works fine:
(for i = 1 to 30 (sleep 500) (maintest 9))
Also tried with test 5, and a couple others at random. This will
work in rapid fire also:
(for i = 1 to 30 (maintest 16))
Further, tests 1-50 work fine with some sleeping:
(for i = 1 to 50 (sleep 500) (maintest i))
However, if you wave the mouse over the sim window you'll get 'Invalid
command name "0" errors' which don't stop the tests from passing.
(Those must be errors in the GUI event handlers resulting from objects
being deleted out from under their noses.)
Ok, now trying to do tests 1-50 in rapid fire. Well, first try
crashed SWL with "nonrecoverable invalid memory reference". (Add that
to the malformed stack errors I was getting earlier.) Wow, that's
actually a consistent behavior. HMM. Third try and I get hung SWL
windows, but no crash. SWL doesn't seem to be stable enough for
actually deploying anything with it.
"nonrecoverable invalid memory reference" happens on blacksmoker as
well as faith.
I also need to take a look at what's going on with the
threading/errors in SWL, because when I run tests 51-75 (with
sleeping, as above), it currently gets an error on 72, but then keeps
going, accumulating more errors. I haven't looked at my unit tester
in a while, but it could be that my attempts to redefine the error
handlers isn't working correctly under SWL.
Wow, just Segfaulted SWL by trying to go to "Exit" via the menu while
it was in the process of spitting up a bunch of load errors from
_genned_node_code.ss (I'm sure there are some legitimate bugs there.)
Just did 75-100 manually, one at a time and they all passed. (This is
revision 1135.)
Well, alas, no time to really track down these problems now.
[Oops, note: 70 can fail even right after loading. It gets a
number->string error, and further, when run repeatedly, it can spit
out "car: () is not a pair" probably from another thread, a graphics
thread.]
[2006.03.01]
Just got this error, but not from inside SWL:
"sweep_stack(gc): malformed stack"
This time it must have been a stack overflow error, because I was
loading a program that had a quasiquote with a cyclic structure inside
it (even though it was unquoted! hmm!).
[2006.03.03] {Further SWL problems}
Ouch. I'm getting a variety of bad behaviours from SWL. I just wrote
about this in the svn log also. Right now when I run unit tests it
crashes on test 69. But it also spits out a bunch of #f's at the REPL
prompt (other threads returning?). And even though all the tests say
"PASS", a large number of the same error print out repeatedly after it
gets to test 69. What's going on with threading? (What happened to
the "ps-all" "pps" commands that are listed within the manual?) This
is not worth debugging right now, but I really have no idea what's
going on.
Sample:
69 (parameterize ((unique-name-counter 0) (simalpha-dbg-on #f) (simalp... -> Satisfy oracle? #<procedure>: default-unit-tester, got ERROR:
(#f "~?. Some debugging context lost" "invalid memory reference" ())
default-unit-tester, got ERROR:
(#f "~?. Some debugging context lostdefault-unit-tester, got ERROR:
(#f "invalid command name \"0\"")
FAIL: Expected result to satisfy procedure: #<procedure>
Received:
error
[2006.03.08]
Wow, just ran my system under ubuntu on my macbook pro 1.83 ghz.
With revision 1150, (opt lvl 3, no debug) it completed my unit tests
faster than any other computer that I use.
(time (tu))
1053 collections
9336 ms elapsed cpu time, including 2764 ms collecting
9412 ms elapsed real time, including 2747 ms collecting
903636344 bytes allocated, including 881799464 bytes reclaimed
[2006.04.05]
[2007.02.24]
Does chez not have a TCP library except in SWL? SWL's a bit
heavyweight and it would be annoying to have to use it for all
command-line invocations.
(What did TOSSIM use? Or am I thinking of something I saw at MSR?)
xgraph
[2007.02.24] {Adding a new numeric datatype}
Adding Int16... these are the things that had to change:
*) Add conversion procedures to prim_defs.ss, wavescript_sim_library, static-elaborate
*) Added to list of num types in type_environments (now in prim_defs)
Also, in type_environments, update constant-typeable-as? and type->width.
After adding arith primitives, you'll need to implement them in
wavescript_sim_library_push.sls
*) Changed the type checker to allow constants of special int types,
the convention is that they be always wrapped in (assert-type ...)
forms. This change has been made and shouldn't be needed again.
*) Add to emit-c for printing, reading, and arithmetic
.
NOTE! Also need to add to degeneralize-arithmetic !! - [2007.07.12]
NOTE! Also need to add to grammar.ss - [2007.07.27] (no, not anymore)
NOTE! Now you don't add full conversion primitives, you just extend cast_num - [2008.06.27]
[2007.03.05]
Just got a segfault on demo3f which I can't now reproduce... strange.
[2007.03.08]
Eventually I would like a foreign function entry to look something
like this:
foo :: (Matrix Complex, Array Int, Matrix Complex) -> Int;
foo = foreign("gsl_linalg_complex_LU_invert",
[GSLComplexMatrixType, GSLPermType, GSLComplexMatrixType], IntType,
[Include "gsl/gsl_matrix.h", Include "gsl/gsl_linalg.h",
Link "gsl.so", Link "gslcblas.so"]);
f = fun(x)
numtypecase(x) {
Int: ...
Float: ...
}
case(x){
Foo(a,b): ...;
Bar(a,b): ...;
Baz(head:::tail): ...;
}
================================================================================
[2007.03.10] {Syntax choices}
Thinking about different syntax here...
let s2 as (x,y) = ...
s2 as (x,y) = ...
s2.x s2.(x,x,y)
s2@x s2@(x,x,y)
s2:x s2:(x,x,y)
s2|x s2|(x,x,y)
s2.(x) s2.(x,x,y)
s2.<x> s2.<x,x,y>
x@s2, (x,x,y)@s2
x from s2, (x,x,y) from s2
case (x) {
First z | z + 3;
Second z | z + 4;
}
case (x) {
First z -> z + 3;
Second z -> z + 4;
}
case (x) {
First z > z + 3;
Second z > z + 4;
}
switch (x) {
| First z -> z + 3
| Second z -> z + 4
}
match x {
First z -> z + 3
| Second z -> z + 4
}
match x {
| First z | z + 3
| Second z | z + 4
}
match x {
| First z : z + 3
| Second z : z + 4
}
switch (x) {
case First z -> z + 3
case Second z -> z + 4
}
iterate( (x,y) in s2 ) { emit (x,x,y) }
ls.head
================================================================================
[2007.03.14]
Extensible records should just desugar into plain tuples because of
our meta-programming approach.
{ x | a=3, b=4 }
{ a=3, b=4; } !!ACK need more delimiters!!
( x | a=3 )
( ( a=3, b=4) | c=5 )
(| a = 3)
(|)
< x | c=3 >
<a=3, b=4>
If we do get records, then we'll probably need to push the modified
application syntax to a different character.
ls.tail.tail.head
ls#tail#tail#head
ls # tail # tail # head
ls$ tail$ tail$ head
ls$tail$tail$head
ls%tail%tail%head
ls@tail@tail@head
ls|tail|tail|head
ls.ref(n)
ls|ref(n)
ls\ref(n)
ls\tail\tail\head -- That's not bad!
ls \ tail \ tail \ head
Kinda denotes going "backwards" which is what the function application
is doing...
ls \tail \tail \head
ls\ tail\ tail\ head
head( tail( tail(ls)))
x\f
x\f(y)
f(x,y)
w\length
w|length
w%length
================================================================================
[2007.03.28] {More Syntax}
If I did implement type classes, what syntax for the types would I use?
x :: a -> String where Num a
x :: a -> String | Num a
x :: Num a | a -> String
x :: Num a . a -> String
x :: Num a => a -> String
x :: a -> b | Num a, Foo b;
{x | a=3 }
{| a=3 }
{| }
To implement records on top of type classes, why did it seem to Greg &
I that you needed multi-parameter type classes? "Has" doesn't need to
reify the type as one of its arguments.... it seems like we can just
generate a "Has_x" class for every label that occurs in the input
program. Oh, you need a parameter to represent the output type of the
field.
class Has_x a b where
proj_x :: a -> b
How do we translate a record expression?
{| x=3 } :: a | Has_x a b, Num b
{| x='s' } :: a | Has_x a Char
{| x=3, y=4.0 }
(3,4.0) :: (Int * Float) |
Has_x (Int * Float) Int,
Has_y (Int * Float) Float
instance Has_x (Int*Float) Int where
proj_x (i,_) -> i
e.x ==> proj_x e :: b | Has_x a b
Uh, need functional dependencies???
[2007.04.06] {Source locations}
I'm thinking of making the relatively wide-reaching change of
including source-position information. At least as far as the
type-checker.
Maybe as I push through this wave of changes I should move over to
using vectors for ASTs also. However, first I'm trying to ascertain
if there's really any performance benefit. This simple test seems to
say that there isn't at all!!
(collect 4)(time (rep 100000 (match '(foo 1 2 3) [(foo ,x ,y) 'no] [(bar ,x ,y ,z) 'no] [(foo ,x ,y ,z) 'yes])))
(collect 4)(time (rep 100000 (match #(foo 1 2 3) [#(foo ,x ,y) 'no] [#(bar ,x ,y ,z) 'no] [#(foo ,x ,y ,z) 'yes])))
32 collections
64 ms elapsed cpu time, including 4 ms collecting
64 ms elapsed real time, including 5 ms collecting
35052176 bytes allocated, including 34308880 bytes reclaimed
41 collections
80 ms elapsed cpu time, including 8 ms collecting
79 ms elapsed real time, including 8 ms collecting
44654232 bytes allocated, including 44460776 bytes reclaimed
Here's a slightly more complex test that rebuilds the data structure as well:
(collect 4)(time (rep 50000 (match #(foo 1 2 #(bar 3 4 5)) [#(foo ,x ,y) 'no]
[#(bar ,[x] ,[y] ,[z]) `#(bar ,x ,y ,z)] [#(foo ,[x] ,[y] ,[z]) `#(foo ,x ,y ,z)] [,_ 0])))
(collect 4)(time (rep 50000 (match '(foo 1 2 (bar 3 4 5)) [(foo ,x ,y) 'no]
[(bar ,[x] ,[y] ,[z]) `(bar ,x ,y ,z)] [(foo ,[x] ,[y] ,[z]) `(foo ,x ,y ,z)] [,_ 0])))
136 collections
316 ms elapsed cpu time, including 136 ms collecting
318 ms elapsed real time, including 125 ms collecting
147311072 bytes allocated, including 146858896 bytes reclaimed
123 collections
236 ms elapsed cpu time, including 72 ms collecting
234 ms elapsed real time, including 74 ms collecting
136940584 bytes allocated, including 136467768 bytes reclaimed
[ Doesn't get much from opt-level 3 ]
Lists win again!!!
Just for reference let's try records.
Ideally this would look something like the vector case:
(match #[foo 1 2 3] [#[foo ,x ,y ,z] ...])
(match (make-foo 1 2 3) [[record foo ,x ,y ,z] ...])
But alas match doesn't handle records.
(define-record foo (x y z))
(define-record foo2 (x y))
(define-record bar (x y z))
(collect 4)
(time (rep 50000
(let f ([r (make-foo 1 2 (make-bar 3 4 5))])
(cond
[(foo2? r) 'no]
[(bar? r) (make-bar (f (bar-x r)) (f (bar-y r)) (f (bar-z r)))]
[(foo? r) (make-foo (f (foo-x r)) (f (foo-y r)) (f (foo-z r)))]
[else 0]))))
3 collections
16 ms elapsed cpu time, including 0 ms collecting
19 ms elapsed real time, including 0 ms collecting
3200720 bytes allocated, including 3185704 bytes reclaimed
[ Doesn't get much from opt-level 3 ]
Well, that's not much of a contest, is it? Surprising that the
allocation is so much better for the records case, but worse for the
vector case. Where's all the allocation for the vectors? Is it
closure allocation from the match system?
Let's try my r5rs syntax-rules based match. SIGH... it beats the
pants off the other match.ss
(collect 4)(time (rep 50000 (match '(foo 1 2 (bar 3 4 5)) [(foo ,x ,y) 'no]
[(bar ,[x] ,[y] ,[z]) `(bar ,x ,y ,z)] [(foo ,[x] ,[y] ,[z]) `(foo ,x ,y ,z)] [,_ 0])))
24 collections
84 ms elapsed cpu time, including 4 ms collecting
87 ms elapsed real time, including 1 ms collecting
24805568 bytes allocated, including 25449056 bytes reclaimed
(Then on opt-level 3 that drops down to 34 ms.)
(Took out delay-values and got that down to 77 opt0 and 32 in opt3)
(Then took out the ASSERT on literals, and that brought it to 69ms/30ms)
HMM... My current r5rs matcher doesn't support vector patterns. But
here's a simple rewrite of the record example above for vectors. This
does really well!
(collect 4)
(time (rep 50000
(let f ([r (vector 'foo 1 2 (vector 'bar 3 4 5))])
(cond
[(and (vector? r) (= (vector-length r) 3) (equal? 'foo (vector-ref r 0))) 'no]
[(and (vector? r) (= (vector-length r) 4) (equal? 'bar (vector-ref r 0)))
(vector 'bar (f (vector-ref r 1)) (f (vector-ref r 2)) (f (vector-ref r 3)))]
[(and (vector? r) (= (vector-length r) 4) (equal? 'foo (vector-ref r 0)))
(vector 'foo (f (vector-ref r 1)) (f (vector-ref r 2)) (f (vector-ref r 3)))]
[else 0]))))
4 collections
8 ms elapsed cpu time, including 0 ms collecting
9 ms elapsed real time, including 0 ms collecting
4800928 bytes allocated, including 4224800 bytes reclaimed
OOOPS! SHOULDN'T USE A QUOTED CONSTANT DIRECTLY... The optimizer can
then cheat. Here, I reran the above, fixing that, and got pretty
similar results:
(collect 4)(define val '(foo 1 2 (bar 3 4 5)))
(time (rep 50000 (match val [(foo ,x ,y) 'no]
[(bar ,[x] ,[y] ,[z]) `(bar ,x ,y ,z)] [(foo ,[x] ,[y] ,[z]) `(foo ,x ,y ,z)] [,_ 0])))
(collect 4)(define val #(foo 1 2 #(bar 3 4 5)))
(time (rep 50000 (match val [#(foo ,x ,y) 'no]
[#(bar ,[x] ,[y] ,[z]) `#(bar ,x ,y ,z)] [#(foo ,[x] ,[y] ,[z]) `#(foo ,x ,y ,z)] [,_ 0])))
(define-record foo (x y z))
(define-record foo2 (x y))
(define-record bar (x y z))
(define val (make-foo 1 2 (make-bar 3 4 5)))
(collect 4)
(time (rep 50000
(let f ([r val])
(cond
[(foo2? r) 'no]
[(bar? r) (make-bar (f (bar-x r)) (f (bar-y r)) (f (bar-z r)))]
[(foo? r) (make-foo (f (foo-x r)) (f (foo-y r)) (f (foo-z r)))]
[else 0]))))
(collect 4)
(define val (vector 'foo 1 2 (vector 'bar 3 4 5)))
(time (rep 50000
(let f ([r val])
(cond
[(and (vector? r) (= (vector-length r) 3) (equal? 'foo (vector-ref r 0))) 'no]
[(and (vector? r) (= (vector-length r) 4) (equal? 'bar (vector-ref r 0)))
(vector 'bar (f (vector-ref r 1)) (f (vector-ref r 2)) (f (vector-ref r 3)))]
[(and (vector? r) (= (vector-length r) 4) (equal? 'foo (vector-ref r 0)))
(vector 'foo (f (vector-ref r 1)) (f (vector-ref r 2)) (f (vector-ref r 3)))]
[else 0]))))
(collect 4)
(define val (list 'foo 1 2 (list 'bar 3 4 5)))
(time (rep 50000
(let f ([r val])
(cond
[(and (list? r) (= (length r) 3) (equal? 'foo (car r))) 'no]
[(and (list? r) (= (length r) 4) (equal? 'bar (car r)))
(list 'bar (f (cadr r)) (f (caddr r)) (f (cadddr r)))]
[(and (list? r) (= (length r) 4) (equal? 'foo (car r)))
(list 'foo (f (cadr r)) (f (caddr r)) (f (cadddr r)))]
[else 0]))))
;; INCORRECT, but gives us a lower bound:
(collect 4)
(define val (list 'foo 1 2 (list 'bar 3 4 5)))
(time (rep 50000
(let f ([r val])
(cond
[(and (pair? r) (equal? 'foo (car r)) (= (length r) 3) ) 'no]
[(and (pair? r) (equal? 'bar (car r)) (= (length r) 4) )
(list 'bar (f (cadr r)) (f (caddr r)) (f (cadddr r)))]
[(and (pair? r) (equal? 'foo (car r)) (= (length r) 4))
(list 'foo (f (cadr r)) (f (caddr r)) (f (cadddr r)))]
[else 0]))))
(match #(foo 1 2 #(bar 3 4 5))
[#(foo ,x ,y) 'no]
[#(bar ,[x] ,[y] ,[z]) `#(bar ,x ,y ,z)]
[#(foo ,[x] ,[y] ,[z]) `#(foo ,x ,y ,z)]
[,_ 0])
(expand '(match #(foo 1 2 #(bar 3 4 5))
[#(foo ,x ,y) 'no]
[#(foo ,[x] ,[y] ,[z]) `#(foo ,x ,y ,z)]))
(expand/optimize '(match #(foo 1 2 #(bar 3 4 5))
[#(foo ,x ,y) 'no]
[#(foo ,[x] ,[y] ,[z]) `#(foo ,x ,y ,z)]))
[2007.04.16]
Switched the DEFINE_OUTPUT_TYPE macro back to the default one rather
than my WS_ version. It seemed to reduce crashing in wsc code, but it
still gets double-free errors. (Now it got a floating point exception
anyway.)
[2007.05.03] {Linking GSL}
When loading libraries into Scheme, it seems that they can't see
*eachother*. That is, I need to link together all co-dependent .so
files and then load the final product into Chez.
[2007.05.10] {Should we use dlopen?}
.
Otherwise where do we get the "Pointer" types from for generating the
right calls to foreign procedures? We could somehow require them in
the "foreign" entry... but that's rather cumbersome. I'd wanted them
all to be (void*), but that results in the C compiler throwing type
errors unless there are casts. There's something nice about requiring
that the foreign code be compiled and only supporting it through
dlopen...
.
OR could have another keyword...
.
foreign "foo" in ["foo.so"] pointerargs ["foobar_t *"]
.
This would let us typecheck the code properly.
[2007.05.14] {Trying to optimize PLT version a little bit.}
.
Performing a test on demo3a_tuples.ws. (Takes 12ms to compile in chez
with the normal "ws" command.)
.
Baseline, from source: 4361 ms (1680 typechecking)
Compiled .zo's : 5652 2330
With --prim : 5572 2284
With all --unsafe : 4920 4938
AHA! This turns out to be a profoundly broken iu-match package.
By switching over to rn-match for the typechecker and static
elaborator, this dropped a lot (2 secs were spend in type checker, 1
in elaborator -- this was almost entirely eliminated). That got us
down to ~2 secs.. Applying rn-match to generic-traversal got us down
to 600ms. Still much worse than 12ms but an improvement!
(time (let f ([n 50000])
(unless (= 0 n)
(let l ([v '(foo 1 2 (bar 3 4 5))])
(match v
[('foo x y) 'no]
[('bar x y z) `(bar ,(l x) ,(l y) ,(l z))]
[('foo x y z) `(foo ,(l x) ,(l y) ,(l z))]
[_ 0]))
(f (- n 1)))))
(define top '(foo 1 2 (bar 3 4 5)))
(time (let f ([n 50000])
(unless (= 0 n)
(let l ([v top])
(match v
[(foo ,x ,y) 'no]
[(bar ,x ,y ,z) `(bar ,(l x) ,(l y) ,(l z))]
[(foo ,x ,y ,z) `(foo ,(l x) ,(l y) ,(l z))]
[,_ 0]))
(f (- n 1)))))
(define top '(foo 1 2 (bar 3 4 5)))
(time (let f ([n 50000])
(unless (= 0 n)
(match v
[(foo ,x ,y) 'no]
[(bar ,[x] ,[y] ,[z]) `(bar ,x ,y ,z)]
[(foo ,[x] ,[y] ,[z]) `(foo ,x ,y ,z)]
[,_ 0])
(f (- n 1)))))
[2007.05.30] {Thinking about adding static annotations}
.
But what do they annotate?
Ultimately, we want to designate certain *allocating* operations
(list, array, hash-table creation) as being static.
.
This could be done in several ways. Alternate versions of those
allocating operators, perhaps expressed as an annotation *to* the
operator itself. Or an annotation on a whole lexical scope (applying
to all operators within it). Or an annotation on a variable binding,
indicating that *that value* is never collected.
.
But, because the (static) values will have a different type, the
static designation also needs to be carried in the types. Again, do
we have a (StaticArray 'a) type? Or do we have just one new
type-constructor: (Static (Array 'a)).
.
After thinking about this a bit more it seems like I should add in
explicit operators for ref-counting an object, and expose those to the
compiler. But will that mess up my ability to use intrusive_ptrs?
I need to talk to Greg about this.
[2007.06.06] {Trying hash tables for type environments.}
Testing compiler on pothole3.ws.
tenv-extend is called 7035 times.
tenv-lookup is called 8403 times.
For HASH based tenvs:
(Note this uses one table for the whole tree traversal of the program.)
The average size of the tenv being extended is 676.
The median size is 435.
For LIST based tenvs:
Average size at extension is 87.
Median size at extension is 81.
Average size at lookup is 75.26.
Median size at lookup is 55.0.
LIST BASED: total elab typecheck
ws: 2098 1247 322
ws.opt: 1580 934 206
HASH TABLES, SIZE 100:
ws: 3008 1261 333
ws.opt: 2247 951 214
HASH TABLES, SIZE 1000:
ws: 2967 1238 329
ws.opt: 2274 941 215
[2007.06.19]
.
Well on the newest version of demo3g the struct-based arrays run twice
as fast as the old "vector"-class based ones (on -O3, 2 seconds vs. 1
second). Demo3g is invariant to one vs. two processors (it does a big
loop *inside* an iterate, rather than passing lots of data across channels).
As long as one processor is disabled (so it's uniprocessor), these do
about the same on faith with -O3 and running with -j 1. (Actually the
-j 1 doesn't make much difference either way.)
[2007.06.23] {porting Mlton ARM cross compiler}
Trying to hack up a MLton ARM cross compiler.
Looking for the ARM equivalent to the following i386 linux code:
(in linux.c)
ucontext_t* ucp = (ucontext_t*)mystery;
GC_handleSigProf ((code_pointer) ucp->uc_mcontext.gregs[EIP]);
arm-linux-gcc -I/usr/arm-linux/include -I. -o print-constants print-constants.c libmlton.a libgdtoa.a /usr/arm-linux/lib/libgmp.so -lm 2> /dev/stdout
Ok... got cross compiling working for "hello world"... but when I try
a more substantial example I run into this:
/usr/lib/mlton/arm-linux/libmlton.a(IEEEReal.o)(.text+0x0): In function `IEEEReal_getRoundingMode':
: warning: warning: fegetround is not implemented and will always fail
/usr/lib/mlton/arm-linux/libmlton.a(IEEEReal.o)(.text+0x4): In function `IEEEReal_setRoundingMode':
: warning: warning: fesetround is not implemented and will always fail
.tmp.1.o(.text+0x2e8c): In function `$a':
: undefined reference to `Chunk0'
.tmp.1.o(.text+0x8ee8): In function `$a':
: undefined reference to `Chunk0'
.tmp.1.o(.text+0xae68): In function `$a':
: undefined reference to `Chunk0'
.tmp.0.o(.text+0x654): In function `main':