You can subscribe to this list here.
2009 |
Jan
|
Feb
(3) |
Mar
(1) |
Apr
|
May
|
Jun
(5) |
Jul
(3) |
Aug
(5) |
Sep
(2) |
Oct
(6) |
Nov
(2) |
Dec
(1) |
---|---|---|---|---|---|---|---|---|---|---|---|---|
2010 |
Jan
(16) |
Feb
(1) |
Mar
(10) |
Apr
(4) |
May
(3) |
Jun
|
Jul
(1) |
Aug
(1) |
Sep
(1) |
Oct
(3) |
Nov
|
Dec
(1) |
2011 |
Jan
(3) |
Feb
(6) |
Mar
|
Apr
(2) |
May
(4) |
Jun
(5) |
Jul
(1) |
Aug
(8) |
Sep
(1) |
Oct
(1) |
Nov
(2) |
Dec
(1) |
2012 |
Jan
(2) |
Feb
(2) |
Mar
(8) |
Apr
(6) |
May
(13) |
Jun
(6) |
Jul
(3) |
Aug
(2) |
Sep
(7) |
Oct
(1) |
Nov
|
Dec
|
2013 |
Jan
(5) |
Feb
(1) |
Mar
(6) |
Apr
(1) |
May
(1) |
Jun
(11) |
Jul
(9) |
Aug
|
Sep
(4) |
Oct
|
Nov
(12) |
Dec
(6) |
2014 |
Jan
(6) |
Feb
(17) |
Mar
(3) |
Apr
(3) |
May
|
Jun
(4) |
Jul
|
Aug
(7) |
Sep
(2) |
Oct
(4) |
Nov
(1) |
Dec
(1) |
2015 |
Jan
(2) |
Feb
(1) |
Mar
(6) |
Apr
(2) |
May
|
Jun
(5) |
Jul
(7) |
Aug
(2) |
Sep
(5) |
Oct
(3) |
Nov
(16) |
Dec
(15) |
2016 |
Jan
(11) |
Feb
(11) |
Mar
(5) |
Apr
|
May
(3) |
Jun
|
Jul
|
Aug
|
Sep
(2) |
Oct
|
Nov
|
Dec
(1) |
2017 |
Jan
(2) |
Feb
|
Mar
(3) |
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2018 |
Jan
|
Feb
|
Mar
(2) |
Apr
(12) |
May
|
Jun
(1) |
Jul
|
Aug
(2) |
Sep
|
Oct
(4) |
Nov
|
Dec
|
2019 |
Jan
|
Feb
(6) |
Mar
|
Apr
(4) |
May
|
Jun
(2) |
Jul
(9) |
Aug
|
Sep
(12) |
Oct
(2) |
Nov
|
Dec
(8) |
2020 |
Jan
(12) |
Feb
(3) |
Mar
(4) |
Apr
(4) |
May
(27) |
Jun
(14) |
Jul
(3) |
Aug
(7) |
Sep
(1) |
Oct
(1) |
Nov
(2) |
Dec
(3) |
2021 |
Jan
(2) |
Feb
(6) |
Mar
(8) |
Apr
(10) |
May
(1) |
Jun
(8) |
Jul
(4) |
Aug
(9) |
Sep
(1) |
Oct
(7) |
Nov
(6) |
Dec
(8) |
2022 |
Jan
(7) |
Feb
(4) |
Mar
(3) |
Apr
(2) |
May
(2) |
Jun
(3) |
Jul
(14) |
Aug
(15) |
Sep
(13) |
Oct
(16) |
Nov
(5) |
Dec
(6) |
2023 |
Jan
(18) |
Feb
(2) |
Mar
(28) |
Apr
(8) |
May
(3) |
Jun
(24) |
Jul
(11) |
Aug
(22) |
Sep
(20) |
Oct
(27) |
Nov
(12) |
Dec
(2) |
2024 |
Jan
(5) |
Feb
(45) |
Mar
(45) |
Apr
(25) |
May
(10) |
Jun
(23) |
Jul
(20) |
Aug
(5) |
Sep
(2) |
Oct
|
Nov
|
Dec
|
From: Stas B. <sta...@gm...> - 2024-03-02 10:20:56
|
This thing seems to do its own networking, so can't help there. On Sat, Mar 2, 2024 at 12:19 PM Daniel Hensel via Sbcl-bugs < sbc...@li...> wrote: > Hello, > > this problem seems to be related to SBCL and its compiler on ARM-Macs, > since it doesn’t occur on Intel machines. I use the software incudine a > lot, that needs to run via SBCL. The thing is, that I cannot open UDP > ports. > > (incudine.osc:open :port 1337 :host "127.0.0.1" :direction :input > :protocol :udp) > > leads to > > OSC:OPEN Failed to assign the address. (Destination address required) > [Condition of type INCUDINE-NETWORK-ERROR] > > Restarts: > 0: [RETRY] Retry SLIME REPL evaluation request. > 1: [*ABORT] Return to SLIME's top level. > 2: [ABORT] abort thread (#<THREAD "repl-thread" RUNNING {70039106C3}>) > > Backtrace: > 0: (INCUDINE.OSC:OPEN :HOST "127.0.0.1" :PORT 1337 :DIRECTION :INPUT > :PROTOCOL :UDP :BUFFER-SIZE NIL :LATENCY 0 :AUTO-CONNECT-P T :MAX-VALUES > NIL :MESSAGE-ENCODING NIL :INPUT-STREAM-CONSTRUCTOR NIL :OUTP.. > Locals: > #:.DEFAULTING-TEMP. = "127.0.0.1" > #:.DEFAULTING-TEMP.#1 = 1337 > #:.DEFAULTING-TEMP.#2 = :INPUT > #:.DEFAULTING-TEMP.#3 = :UDP > #:.DEFAULTING-TEMP.#4 = NIL > #:.DEFAULTING-TEMP.#5 = 0 > #:.DEFAULTING-TEMP.#6 = NIL > #:.DEFAULTING-TEMP.#7 = NIL > #:.DEFAULTING-TEMP.#8 = NIL > #:.DEFAULTING-TEMP.#9 = NIL > ADDRESS = #.(SB-SYS:INT-SAP #X6000038FC000) > AUTO-CONNECT-P = T > AUX-PTR = #.(SB-SYS:INT-SAP #X00000000) > BUF-PTR = #.(SB-SYS:INT-SAP #X107808200) > DIRECTION = :INPUT > FDS-PTR = #.(SB-SYS:INT-SAP #X1078087E8) > #:N-SUPPLIED-0 = 0 > #:N-SUPPLIED-1 = 0 > #:N-SUPPLIED-2 = 0 > #:N-SUPPLIED-3 = 0 > OBJ = #<OSC:INPUT-STREAM :UDP "127.0.0.1" 1337> > PROTOCOL = :UDP > TYPE-VEC-PTR = #.(SB-SYS:INT-SAP #X600002DF8000) > VALUE-VEC-PTR = #.(SB-SYS:INT-SAP #X105004190) > 1: (SB-INT:SIMPLE-EVAL-IN-LEXENV (INCUDINE.OSC:OPEN :PORT 1337 :HOST > "127.0.0.1" :DIRECTION ...) #<NULL-LEXENV>) > 2: (EVAL (INCUDINE.OSC:OPEN :PORT 1337 :HOST "127.0.0.1" :DIRECTION ...)) > --more-- > > Do you have an idea how to solve this problem? > > Yours, > Daniel > > _______________________________________________ > Sbcl-bugs mailing list > Sbc...@li... > https://lists.sourceforge.net/lists/listinfo/sbcl-bugs > |
From: Daniel H. <dan...@ic...> - 2024-03-02 07:43:51
|
Hello, this problem seems to be related to SBCL and its compiler on ARM-Macs, since it doesn’t occur on Intel machines. I use the software incudine a lot, that needs to run via SBCL. The thing is, that I cannot open UDP ports. (incudine.osc:open :port 1337 :host "127.0.0.1" :direction :input :protocol :udp) leads to OSC:OPEN Failed to assign the address. (Destination address required) [Condition of type INCUDINE-NETWORK-ERROR] Restarts: 0: [RETRY] Retry SLIME REPL evaluation request. 1: [*ABORT] Return to SLIME's top level. 2: [ABORT] abort thread (#<THREAD "repl-thread" RUNNING {70039106C3}>) Backtrace: 0: (INCUDINE.OSC:OPEN :HOST "127.0.0.1" :PORT 1337 :DIRECTION :INPUT :PROTOCOL :UDP :BUFFER-SIZE NIL :LATENCY 0 :AUTO-CONNECT-P T :MAX-VALUES NIL :MESSAGE-ENCODING NIL :INPUT-STREAM-CONSTRUCTOR NIL :OUTP.. Locals: #:.DEFAULTING-TEMP. = "127.0.0.1" #:.DEFAULTING-TEMP.#1 = 1337 #:.DEFAULTING-TEMP.#2 = :INPUT #:.DEFAULTING-TEMP.#3 = :UDP #:.DEFAULTING-TEMP.#4 = NIL #:.DEFAULTING-TEMP.#5 = 0 #:.DEFAULTING-TEMP.#6 = NIL #:.DEFAULTING-TEMP.#7 = NIL #:.DEFAULTING-TEMP.#8 = NIL #:.DEFAULTING-TEMP.#9 = NIL ADDRESS = #.(SB-SYS:INT-SAP #X6000038FC000) AUTO-CONNECT-P = T AUX-PTR = #.(SB-SYS:INT-SAP #X00000000) BUF-PTR = #.(SB-SYS:INT-SAP #X107808200) DIRECTION = :INPUT FDS-PTR = #.(SB-SYS:INT-SAP #X1078087E8) #:N-SUPPLIED-0 = 0 #:N-SUPPLIED-1 = 0 #:N-SUPPLIED-2 = 0 #:N-SUPPLIED-3 = 0 OBJ = #<OSC:INPUT-STREAM :UDP "127.0.0.1" 1337> PROTOCOL = :UDP TYPE-VEC-PTR = #.(SB-SYS:INT-SAP #X600002DF8000) VALUE-VEC-PTR = #.(SB-SYS:INT-SAP #X105004190) 1: (SB-INT:SIMPLE-EVAL-IN-LEXENV (INCUDINE.OSC:OPEN :PORT 1337 :HOST "127.0.0.1" :DIRECTION ...) #<NULL-LEXENV>) 2: (EVAL (INCUDINE.OSC:OPEN :PORT 1337 :HOST "127.0.0.1" :DIRECTION ...)) --more-- Do you have an idea how to solve this problem? Yours, Daniel |
From: Hraban <hr...@0b...> - 2024-03-02 02:34:39
|
(not a contributor but I think I know this) Unless SBCL is aware of `2log` and `expt` being mathematical complements, it will have to compute the intermediate result. 2^23 is ~8e6 = ~1MB (give or take some storage inefficiency)--that's no problem. 2^65 = ... a lot. I'm assuming sbcl doesn't do a "2log & expt folding" optimization pass, and I doubt it'd be useful outside of synthetic edge case tests. On 3/1/24 7:45 PM, Robert Boyer wrote: > Dear bug fixers for, as far as I know, the best programming language > system that ever was, > > I did not realize that bignums had a limit! But they seem to. Or am I > wrong? > > Maybe I should go ask one of those supposedly smart AI chat engines for > help. > > * (log (integer-length (expt 2 (expt 2 23))) 2) > 23.0 > * (log (integer-length (expt 2 (expt 2 65)))) > > debugger invoked on a SIMPLE-ERROR in thread > #<THREAD "main thread" RUNNING {1001348003}>: > can't represent result of left shift > > Type HELP for debugger help, or (SB-EXT:EXIT) to exit from SBCL. > > restarts (invokable by number or by possibly-abbreviated name): > 0: [ABORT] Exit debugger, returning to top level. > > (SB-BIGNUM:BIGNUM-ASHIFT-LEFT #<unavailable argument> #<unavailable > argument> #<unavailable argument>) > 0] > * > > Thanks for all your great help, > > Bob > |
From: <don...@is...> - 2024-03-02 01:44:57
|
How much memory does that $100 laptop have? |
From: Robert B. <rob...@gm...> - 2024-03-02 00:46:45
|
Dear bug fixers for, as far as I know, the best programming language system that ever was, I did not realize that bignums had a limit! But they seem to. Or am I wrong? Maybe I should go ask one of those supposedly smart AI chat engines for help. * (log (integer-length (expt 2 (expt 2 23))) 2) 23.0 * (log (integer-length (expt 2 (expt 2 65)))) debugger invoked on a SIMPLE-ERROR in thread #<THREAD "main thread" RUNNING {1001348003}>: can't represent result of left shift Type HELP for debugger help, or (SB-EXT:EXIT) to exit from SBCL. restarts (invokable by number or by possibly-abbreviated name): 0: [ABORT] Exit debugger, returning to top level. (SB-BIGNUM:BIGNUM-ASHIFT-LEFT #<unavailable argument> #<unavailable argument> #<unavailable argument>) 0] * Thanks for all your great help, Bob |
From: syll-dev <syl...@la...> - 2024-02-22 21:02:32
|
Le jeudi 22 février 2024 à 15:27 -0500, Douglas Katzman a écrit : > It warns because it can not positively conclude that a NIL in A does not > reach the + function. > And no it's not a bug in the compiler, if that's what you're asking. > (I'm not sure what you're asking; I don't think you're asking how to > write this to avoid a warning) > You could try to argue that if *C* is non-nil then both A and B would be > assigned, but it's possible that concurrent assignment to *c* may occur > from another thread in between the bindings, which changes the value in > *c* from NIL to non-NIL. > > Anyway the introduction in the SBCL manual suggests that > "warnings should be read not as ``warning, bad aesthetics detected, you > have no style'' but ``warning, this style keeps the compiler from > understanding the code as well as you might like.''" Ok, thank you for this information. Syll |
From: Douglas K. <do...@go...> - 2024-02-22 20:28:04
|
It warns because it can not positively conclude that a NIL in A does not reach the + function. And no it's not a bug in the compiler, if that's what you're asking. (I'm not sure what you're asking; I don't think you're asking how to write this to avoid a warning) You could try to argue that if *C* is non-nil then both A and B would be assigned, but it's possible that concurrent assignment to *c* may occur from another thread in between the bindings, which changes the value in *c* from NIL to non-NIL. Anyway the introduction in the SBCL manual suggests that "warnings should be read not as ``warning, bad aesthetics detected, you have no style'' but ``warning, this style keeps the compiler from understanding the code as well as you might like.''" |
From: syll-dev <syl...@la...> - 2024-02-22 16:54:50
|
Hello Is this a bug ? It is correct in my code to place nil in variable a. If the condition is defined as a local variable in the let, there is no warning. This code signals a style warning : (defparameter *c* nil) (let* ((a (when *c* 1)) (b (when *c* (+ a 1)))) (print b)) -> ; in: LET* ((A (WHEN *C* 1)) (B (WHEN *C* (+ A 1)))) ; (WHEN *C* 1) ; ==> ; NIL ; ; caught STYLE-WARNING: ; This is not a NUMBER: ; NIL ; See also: ; The SBCL Manual, Node "Handling of Types" ; ; compilation unit finished ; caught 1 STYLE-WARNING condition Syll |
From: <sgo...@gm...> - 2024-02-17 21:02:44
|
On 2/15/24 2:04 PM, Robert Boyer <rob...@gm...> wrote: > Maybe I ask too much, but gc output might use (format stream "~:d" n) on > numbers greater than a certain size. > > Tot 730 15717 26671 17545 1954 9002 5662 3 16 > 16 0 0 20112 0.3 1201529280 [35.8% of 3355443200 max] > > Thanks, (format nil "~{~a~^, ~}" (list 1 2 3)) ==> "1, 2, 3" the ~{ directive will process a list. there are conditionals too. check https://gigamonkeys.com/book/a-few-format-recipes format is powerful and anoying at the same time... |
From: Robert B. <rob...@gm...> - 2024-02-16 22:56:57
|
- Apple M3 Max chip with 16‑core CPU, 40‑core GPU, 16‑core Neural Engine - 128GB unified memory - 8TB SSD storage - I wonder if it would be possible to get such a simple piece of code as msa-1 to run via SBCL on those 40 GPU cores? Can SBCL's threads use those cores? Imagine Arlo Guthrie singing Can you imagine 56 cores all singing 'you can get anything you want at Alice's restaurant?' Maybe I should just try to imagine what one might do with 50 $100 Chromebooks not using threads. Threads totally suck on my $100 Chromebook. Last night Emacs' mode line told me I had a load average of 167! Apologies for sending too many email messages, but there is no cure for addiction. Bob P.S. Only 313 lines, so beautiful to behold. * (disassemble 'msa-1) ; disassembly for MSA-1 ; Size: 1056 bytes. Origin: #x5349D474 ; MSA-1 ; 474: 498B4510 MOV RAX, [R13+16] ; thread.binding-stack-pointer ; 478: 488945F8 MOV [RBP-8], RAX ; 47C: 4C8B4DF0 MOV R9, [RBP-16] ; 480: 49D1F9 SAR R9, 1 ; 483: 49FFC1 INC R9 ; 486: 498BD1 MOV RDX, R9 ; 489: 48D1E2 SHL RDX, 1 ; 48C: 0F80C1030000 JO L31 ; 492: 4F8D1C09 LEA R11, [R9+R9] ; 496: 4C8B4DE8 MOV R9, [RBP-24] ; 49A: 49D1F9 SAR R9, 1 ; 49D: 488B55F0 MOV RDX, [RBP-16] ; 4A1: 48D1FA SAR RDX, 1 ; 4A4: 4929D1 SUB R9, RDX ; 4A7: 498BF9 MOV RDI, R9 ; 4AA: 48D1E7 SHL RDI, 1 ; 4AD: 0F809D030000 JO L30 ; 4B3: 4B8D3C09 LEA RDI, [R9+R9] ; 4B7: 48897DE0 MOV [RBP-32], RDI ; 4BB: 4C8BCF MOV R9, RDI ; 4BE: 49D1F9 SAR R9, 1 ; 4C1: 4983E1FE AND R9, -2 ; 4C5: 488B55F0 MOV RDX, [RBP-16] ; 4C9: 48D1FA SAR RDX, 1 ; 4CC: 49D1F9 SAR R9, 1 ; 4CF: 4901D1 ADD R9, RDX ; 4D2: 498BD1 MOV RDX, R9 ; 4D5: 48D1E2 SHL RDX, 1 ; 4D8: 0F806F030000 JO L29 ; 4DE: 4D8BD1 MOV R10, R9 ; 4E1: 4B8D0412 LEA RAX, [R10+R10] ; 4E5: 488945D8 MOV [RBP-40], RAX ; 4E9: 488B45E8 MOV RAX, [RBP-24] ; 4ED: 483B45F0 CMP RAX, [RBP-16] ; 4F1: 7406 JEQ L0 ; 4F3: 4C395DE8 CMP [RBP-24], R11 ; 4F7: 750B JNE L2 ; 4F9: L0: BA17010050 MOV EDX, #x50000117 ; NIL ; 4FE: L1: 488BE5 MOV RSP, RBP ; 501: F8 CLC ; 502: 5D POP RBP ; 503: C3 RET ; 504: L2: 4883FF04 CMP RDI, 4 ; 508: 0F84E6020000 JEQ L26 ; 50E: 488B45F0 MOV RAX, [RBP-16] ; 512: 493B40F9 CMP RAX, [R8-7] ; 516: 0F833C030000 JNB L32 ; 51C: 488B55F0 MOV RDX, [RBP-16] ; 520: 498B449001 MOV RAX, [R8+RDX*4+1] ; 525: A801 TEST AL, 1 ; 527: 0F85C4020000 JNE L25 ; 52D: 4C8BD8 MOV R11, RAX ; 530: 488B55F0 MOV RDX, [RBP-16] ; 534: 4883C202 ADD RDX, 2 ; 538: 493B50F9 CMP RDX, [R8-7] ; 53C: 0F831A030000 JNB L33 ; 542: 498B449001 MOV RAX, [R8+RDX*4+1] ; 547: A801 TEST AL, 1 ; 549: 0F859F020000 JNE L24 ; 54F: 4C8BC8 MOV R9, RAX ; 552: 4983C2FE ADD R10, -2 ; 556: 498BD2 MOV RDX, R10 ; 559: 48D1E2 SHL RDX, 1 ; 55C: 0F8089020000 JO L23 ; 562: 4B8D1412 LEA RDX, [R10+R10] ; 566: 4C8B55F0 MOV R10, [RBP-16] ; 56A: EB42 JMP L6 ; 56C: 0F1F4000 NOP ; 570: L3: 4D39D9 CMP R9, R11 ; 573: 0F855E020000 JNE L22 ; 579: L4: 41BF4F010050 MOV R15D, #x5000014F ; T ; 57F: L5: 4D8BD9 MOV R11, R9 ; 582: 4D8D4A04 LEA R9, [R10+4] ; 586: 4D3B48F9 CMP R9, [R8-7] ; 58A: 0F83D0020000 JNB L34 ; 590: 4B8B448801 MOV RAX, [R8+R9*4+1] ; 595: A801 TEST AL, 1 ; 597: 0F8537020000 JNE L21 ; 59D: 4C8BC8 MOV R9, RAX ; 5A0: 4180FF17 CMP R15B, 23 ; 5A4: 0F84B9010000 JEQ L20 ; 5AA: 4983C202 ADD R10, 2 ; 5AE: L6: 4939D2 CMP R10, RDX ; 5B1: 7EBD JLE L3 ; 5B3: 4C8D4C24F0 LEA R9, [RSP-16] ; 5B8: 4883EC20 SUB RSP, 32 ; 5BC: 488B55D8 MOV RDX, [RBP-40] ; 5C0: 488B7DE8 MOV RDI, [RBP-24] ; 5C4: 498BF0 MOV RSI, R8 ; 5C7: 4D8971F0 MOV [R9-16], R14 ; 5CB: B908000000 MOV ECX, 8 ; 5D0: 498929 MOV [R9], RBP ; 5D3: 498BE9 MOV RBP, R9 ; 5D6: B862E32C50 MOV EAX, #x502CE362 ; #<FDEFN MSA-1> ; 5DB: FFD0 CALL RAX ; 5DD: 480F42E3 CMOVB RSP, RBX ; 5E1: 4C8B75C8 MOV R14, [RBP-56] ; 5E5: 4C8B45D0 MOV R8, [RBP-48] ; 5E9: L7: 4C8B5DF0 MOV R11, [RBP-16] ; 5ED: 4C8B55D8 MOV R10, [RBP-40] ; 5F1: 4531C9 XOR R9D, R9D ; 5F4: EB50 JMP L10 ; 5F6: 660F1F840000000000 NOP ; 5FF: 90 NOP ; 600: L8: 4C395DD8 CMP [RBP-40], R11 ; 604: 0F85AA000000 JNE L14 ; 60A: 4D3B50F9 CMP R10, [R8-7] ; 60E: 0F8350020000 JNB L35 ; 614: 498BC2 MOV RAX, R10 ; 617: 4D8B7C8001 MOV R15, [R8+RAX*4+1] ; 61C: 4D3B4EF9 CMP R9, [R14-7] ; 620: 0F8342020000 JNB L36 ; 626: 4B8D448E01 LEA RAX, [R14+R9*4+1] ; 62B: 48C1E80A SHR RAX, 10 ; 62F: 25FFFF3F00 AND EAX, 4194303 ; 634: 41C6040400 MOV BYTE PTR [R12+RAX], 0 ; 639: 4F897C8E01 MOV [R14+R9*4+1], R15 ; 63E: 4983C202 ADD R10, 2 ; 642: L9: 4983C102 ADD R9, 2 ; 646: L10: 4C3B4DE0 CMP R9, [RBP-32] ; 64A: 7CB4 JL L8 ; 64C: 4531C9 XOR R9D, R9D ; 64F: 4C8B55F0 MOV R10, [RBP-16] ; 653: 48837DE000 CMP QWORD PTR [RBP-32], 0 ; 658: 7F1A JNLE L13 ; 65A: L11: 498BD0 MOV RDX, R8 ; 65D: E99CFEFFFF JMP L1 ; 662: 660F1F840000000000 NOP ; 66B: 0F1F440000 NOP ; 670: L12: 4983C202 ADD R10, 2 ; 674: L13: 4D3B4EF9 CMP R9, [R14-7] ; 678: 0F83EE010000 JNB L37 ; 67E: 4F8B5C8E01 MOV R11, [R14+R9*4+1] ; 683: 4D3B50F9 CMP R10, [R8-7] ; 687: 0F83E3010000 JNB L38 ; 68D: 4B8D449001 LEA RAX, [R8+R10*4+1] ; 692: 48C1E80A SHR RAX, 10 ; 696: 25FFFF3F00 AND EAX, 4194303 ; 69B: 41C6040400 MOV BYTE PTR [R12+RAX], 0 ; 6A0: 4F895C9001 MOV [R8+R10*4+1], R11 ; 6A5: 4983C102 ADD R9, 2 ; 6A9: 488B7DE0 MOV RDI, [RBP-32] ; 6AD: 4939F9 CMP R9, RDI ; 6B0: 7CBE JL L12 ; 6B2: EBA6 JMP L11 ; 6B4: L14: 4C3955E8 CMP [RBP-24], R10 ; 6B8: 753A JNE L15 ; 6BA: 4D3B58F9 CMP R11, [R8-7] ; 6BE: 0F83B0010000 JNB L39 ; 6C4: 4F8B7C9801 MOV R15, [R8+R11*4+1] ; 6C9: 4D3B4EF9 CMP R9, [R14-7] ; 6CD: 0F83A5010000 JNB L40 ; 6D3: 4B8D448E01 LEA RAX, [R14+R9*4+1] ; 6D8: 48C1E80A SHR RAX, 10 ; 6DC: 25FFFF3F00 AND EAX, 4194303 ; 6E1: 41C6040400 MOV BYTE PTR [R12+RAX], 0 ; 6E6: 4F897C8E01 MOV [R14+R9*4+1], R15 ; 6EB: 4983C302 ADD R11, 2 ; 6EF: E94EFFFFFF JMP L9 ; 6F4: L15: 4D3B58F9 CMP R11, [R8-7] ; 6F8: 0F837E010000 JNB L41 ; 6FE: 4B8B4C9801 MOV RCX, [R8+R11*4+1] ; 703: 4D3B50F9 CMP R10, [R8-7] ; 707: 0F8373010000 JNB L42 ; 70D: 498BC2 MOV RAX, R10 ; 710: 4D8B7C8001 MOV R15, [R8+RAX*4+1] ; 715: F6C101 TEST CL, 1 ; 718: 7546 JNE L19 ; 71A: 488BD9 MOV RBX, RCX ; 71D: 41F6C701 TEST R15B, 1 ; 721: 753A JNE L18 ; 723: 498BD7 MOV RDX, R15 ; 726: 4839D3 CMP RBX, RDX ; 729: 7402 JEQ L16 ; 72B: 7D18 JNL L17 ; 72D: L16: 4D3B4EF9 CMP R9, [R14-7] ; 731: 0F834D010000 JNB L43 ; 737: 4B894C8E01 MOV [R14+R9*4+1], RCX ; 73C: 4983C302 ADD R11, 2 ; 740: E9FDFEFFFF JMP L9 ; 745: L17: 4D3B4EF9 CMP R9, [R14-7] ; 749: 0F8339010000 JNB L44 ; 74F: 4F897C8E01 MOV [R14+R9*4+1], R15 ; 754: 4983C202 ADD R10, 2 ; 758: E9E5FEFFFF JMP L9 ; 75D: L18: CC52 INT3 82 ; OBJECT-NOT-FIXNUM-ERROR ; 75F: 3C BYTE #X3C ; R15(d) ; 760: L19: CC52 INT3 82 ; OBJECT-NOT-FIXNUM-ERROR ; 762: 04 BYTE #X04 ; RCX(d) ; 763: L20: 4C8D4C24F0 LEA R9, [RSP-16] ; 768: 4883EC20 SUB RSP, 32 ; 76C: 488B55F0 MOV RDX, [RBP-16] ; 770: 488B7DD8 MOV RDI, [RBP-40] ; 774: 498BF0 MOV RSI, R8 ; 777: 4D8971F0 MOV [R9-16], R14 ; 77B: B908000000 MOV ECX, 8 ; 780: 498929 MOV [R9], RBP ; 783: 498BE9 MOV RBP, R9 ; 786: B862E32C50 MOV EAX, #x502CE362 ; #<FDEFN MSA-1> ; 78B: FFD0 CALL RAX ; 78D: 480F42E3 CMOVB RSP, RBX ; 791: 4C8B75C8 MOV R14, [RBP-56] ; 795: 4C8B45D0 MOV R8, [RBP-48] ; 799: 4C8D4C24F0 LEA R9, [RSP-16] ; 79E: 4883EC20 SUB RSP, 32 ; 7A2: 488B55D8 MOV RDX, [RBP-40] ; 7A6: 488B7DE8 MOV RDI, [RBP-24] ; 7AA: 498BF0 MOV RSI, R8 ; 7AD: 4D8971F0 MOV [R9-16], R14 ; 7B1: B908000000 MOV ECX, 8 ; 7B6: 498929 MOV [R9], RBP ; 7B9: 498BE9 MOV RBP, R9 ; 7BC: B862E32C50 MOV EAX, #x502CE362 ; #<FDEFN MSA-1> ; 7C1: FFD0 CALL RAX ; 7C3: 480F42E3 CMOVB RSP, RBX ; 7C7: 4C8B75C8 MOV R14, [RBP-56] ; 7CB: 4C8B45D0 MOV R8, [RBP-48] ; 7CF: E915FEFFFF JMP L7 ; 7D4: L21: CC52 INT3 82 ; OBJECT-NOT-FIXNUM-ERROR ; 7D6: 00 BYTE #X00 ; RAX(d) ; 7D7: L22: 4D39CB CMP R11, R9 ; 7DA: 0F8C99FDFFFF JL L4 ; 7E0: 41BF17010050 MOV R15D, #x50000117 ; NIL ; 7E6: E994FDFFFF JMP L5 ; 7EB: L23: CC52 INT3 82 ; OBJECT-NOT-FIXNUM-ERROR ; 7ED: 2A BYTE #X2A ; R10(s) ; 7EE: L24: CC52 INT3 82 ; OBJECT-NOT-FIXNUM-ERROR ; 7F0: 00 BYTE #X00 ; RAX(d) ; 7F1: L25: CC52 INT3 82 ; OBJECT-NOT-FIXNUM-ERROR ; 7F3: 00 BYTE #X00 ; RAX(d) ; 7F4: L26: 488B45F0 MOV RAX, [RBP-16] ; 7F8: 493B40F9 CMP RAX, [R8-7] ; 7FC: 0F838A000000 JNB L45 ; 802: 488B55F0 MOV RDX, [RBP-16] ; 806: 4D8B549001 MOV R10, [R8+RDX*4+1] ; 80B: 4D3B58F9 CMP R11, [R8-7] ; 80F: 737F JNB L46 ; 811: 4D8BCB MOV R9, R11 ; 814: 4F8B4C8801 MOV R9, [R8+R9*4+1] ; 819: 41F6C101 TEST R9B, 1 ; 81D: 752B JNE L28 ; 81F: 498BC9 MOV RCX, R9 ; 822: 41F6C201 TEST R10B, 1 ; 826: 751F JNE L27 ; 828: 4D8BFA MOV R15, R10 ; 82B: 4C39F9 CMP RCX, R15 ; 82E: 0F8DC5FCFFFF JNL L0 ; 834: 488B55F0 MOV RDX, [RBP-16] ; 838: 4D894C9001 MOV [R8+RDX*4+1], R9 ; 83D: 4F89549801 MOV [R8+R11*4+1], R10 ; 842: E9B2FCFFFF JMP L0 ; 847: L27: CC52 INT3 82 ; OBJECT-NOT-FIXNUM-ERROR ; 849: 28 BYTE #X28 ; R10(d) ; 84A: L28: CC52 INT3 82 ; OBJECT-NOT-FIXNUM-ERROR ; 84C: 24 BYTE #X24 ; R9(d) ; 84D: L29: CC52 INT3 82 ; OBJECT-NOT-FIXNUM-ERROR ; 84F: 26 BYTE #X26 ; R9(s) ; 850: L30: CC52 INT3 82 ; OBJECT-NOT-FIXNUM-ERROR ; 852: 26 BYTE #X26 ; R9(s) ; 853: L31: CC52 INT3 82 ; OBJECT-NOT-FIXNUM-ERROR ; 855: 26 BYTE #X26 ; R9(s) ; 856: CC10 INT3 16 ; Invalid argument count trap ; 858: L32: CC24 INT3 36 ; INVALID-VECTOR-INDEX-ERROR ; 85A: 20 BYTE #X20 ; R8(d) ; 85B: 01 BYTE #X01 ; RAX(a) ; 85C: L33: CC24 INT3 36 ; INVALID-VECTOR-INDEX-ERROR ; 85E: 20 BYTE #X20 ; R8(d) ; 85F: 09 BYTE #X09 ; RDX(a) ; 860: L34: CC24 INT3 36 ; INVALID-VECTOR-INDEX-ERROR ; 862: 20 BYTE #X20 ; R8(d) ; 863: 25 BYTE #X25 ; R9(a) ; 864: L35: CC24 INT3 36 ; INVALID-VECTOR-INDEX-ERROR ; 866: 20 BYTE #X20 ; R8(d) ; 867: 29 BYTE #X29 ; R10(a) ; 868: L36: CC24 INT3 36 ; INVALID-VECTOR-INDEX-ERROR ; 86A: 38 BYTE #X38 ; R14(d) ; 86B: 25 BYTE #X25 ; R9(a) ; 86C: L37: CC24 INT3 36 ; INVALID-VECTOR-INDEX-ERROR ; 86E: 38 BYTE #X38 ; R14(d) ; 86F: 25 BYTE #X25 ; R9(a) ; 870: L38: CC24 INT3 36 ; INVALID-VECTOR-INDEX-ERROR ; 872: 20 BYTE #X20 ; R8(d) ; 873: 29 BYTE #X29 ; R10(a) ; 874: L39: CC24 INT3 36 ; INVALID-VECTOR-INDEX-ERROR ; 876: 20 BYTE #X20 ; R8(d) ; 877: 2D BYTE #X2D ; R11(a) ; 878: L40: CC24 INT3 36 ; INVALID-VECTOR-INDEX-ERROR ; 87A: 38 BYTE #X38 ; R14(d) ; 87B: 25 BYTE #X25 ; R9(a) ; 87C: L41: CC24 INT3 36 ; INVALID-VECTOR-INDEX-ERROR ; 87E: 20 BYTE #X20 ; R8(d) ; 87F: 2D BYTE #X2D ; R11(a) ; 880: L42: CC24 INT3 36 ; INVALID-VECTOR-INDEX-ERROR ; 882: 20 BYTE #X20 ; R8(d) ; 883: 29 BYTE #X29 ; R10(a) ; 884: L43: CC24 INT3 36 ; INVALID-VECTOR-INDEX-ERROR ; 886: 38 BYTE #X38 ; R14(d) ; 887: 25 BYTE #X25 ; R9(a) ; 888: L44: CC24 INT3 36 ; INVALID-VECTOR-INDEX-ERROR ; 88A: 38 BYTE #X38 ; R14(d) ; 88B: 25 BYTE #X25 ; R9(a) ; 88C: L45: CC24 INT3 36 ; INVALID-VECTOR-INDEX-ERROR ; 88E: 20 BYTE #X20 ; R8(d) ; 88F: 01 BYTE #X01 ; RAX(a) ; 890: L46: CC24 INT3 36 ; INVALID-VECTOR-INDEX-ERROR ; 892: 20 BYTE #X20 ; R8(d) ; 893: 2D BYTE #X2D ; R11(a) NIL * |
From: Stas B. <sta...@gm...> - 2024-02-16 09:47:01
|
Except it's non-standard. On Fri, Feb 16, 2024 at 7:40 AM James Cloos <cl...@jh...> wrote: > >>>>> "SB" == Stas Boukarev <sta...@gm...> writes: > > SB> It's written in C, so no ~:d there. > > In printf(3) one uses the '-modifier for that. > > -JimC > -- > James Cloos <cl...@jh...> > OpenPGP: https://jhcloos.com/0x997A9F17ED7DAEA6.asc > |
From: Robert B. <rob...@gm...> - 2024-02-16 05:59:51
|
I suspect that the process-close and close calls below are a good idea. (defun load-average () "(load-average) returns two values: the current load average and the line that uptime prints." (let* ((proc (run-program "/usr/bin/uptime" nil :output :stream)) (o (sb-ext:process-output proc)) (s (read-line o))) (process-close proc) (close o) (let ((n (search "load average: " s))) (values (read-from-string (subseq s (+ n 14))) s)))) |
From: James C. <cl...@jh...> - 2024-02-16 04:58:57
|
>>>>> "SB" == Stas Boukarev <sta...@gm...> writes: SB> It's written in C, so no ~:d there. In printf(3) one uses the '-modifier for that. -JimC -- James Cloos <cl...@jh...> OpenPGP: https://jhcloos.com/0x997A9F17ED7DAEA6.asc |
From: Robert B. <rob...@gm...> - 2024-02-16 04:39:00
|
I failed to find via 'apropos' the function below. If it is already there, please tell me its name. Otherwise, please consider adding it somewhere. (defun load-average () "(load-average) returns two values: the current load average and the line that uptime prints." (let* ((s (read-line (sb-ext:process-output (run-program "/usr/bin/uptime" nil :output :stream)))) (n (search "load average: " s))) (values (read-from-string (subseq s (+ n 14))) s))) Bob |
From: <sgo...@gm...> - 2024-02-16 01:44:46
|
On 2/15/24 2:11 PM, Stas Boukarev <sta...@gm...> wrote: > It's written in C, so no ~:d there. > > On Thu, Feb 15, 2024 at 10:05 PM Robert Boyer > <rob...@gm... <mailto:rob...@gm...>> wrote: > > Maybe I ask too much, but gc output might use (format stream "~:d" > n) on numbers greater than a certain size. > > Tot 730 15717 26671 17545 1954 9002 5662 3 16 > 16 0 0 20112 0.3 1201529280 [35.8% of 3355443200 max] > > Thanks, > > Bob > > _______________________________________________ > Sbcl-bugs mailing list > Sbc...@li... <mailto:Sbc...@li...> > https://lists.sourceforge.net/lists/listinfo/sbcl-bugs > <https://lists.sourceforge.net/lists/listinfo/sbcl-bugs> > with-output-to-string. |
From: Stas B. <sta...@gm...> - 2024-02-15 19:12:02
|
It's written in C, so no ~:d there. On Thu, Feb 15, 2024 at 10:05 PM Robert Boyer <rob...@gm...> wrote: > Maybe I ask too much, but gc output might use (format stream "~:d" n) on > numbers greater than a certain size. > > Tot 730 15717 26671 17545 1954 9002 5662 3 16 16 > 0 0 20112 0.3 1201529280 [35.8% of 3355443200 max] > > Thanks, > > Bob > > _______________________________________________ > Sbcl-bugs mailing list > Sbc...@li... > https://lists.sourceforge.net/lists/listinfo/sbcl-bugs > |
From: Robert B. <rob...@gm...> - 2024-02-15 19:05:09
|
Maybe I ask too much, but gc output might use (format stream "~:d" n) on numbers greater than a certain size. Tot 730 15717 26671 17545 1954 9002 5662 3 16 16 0 0 20112 0.3 1201529280 [35.8% of 3355443200 max] Thanks, Bob |
From: Robert B. <rob...@gm...> - 2024-02-15 00:57:22
|
SBCL is not only great and wonderful but also magnificently beautiful. In only a few hours, at the first knowing nothing about threads, I was able to begin using threads in my merge sort program 'msa' on my Chromebook. Here is all the code that I added, a single 'cond' clause: #+msa-threads ((> end-start 100000) (let ((thread (sb-thread:make-thread (lambda (input) (declare (simple-vector input)) (let ((scratch (make-array (length input)))) (declare (simple-vector scratch)) (sb-thread:return-from-thread (msa-1 0 (length input) input scratch)))) :arguments (list (subseq input start mid))))) (msa-1 mid end input scratch) (let ((output (sb-thread:join-thread thread))) (declare (simple-vector output)) (loop for i fixnum from start below mid as j fixnum below (length output) do (setf (svref input i) (svref output j)))))) Any criticism is most welcome. Thanks so very, very much for SBCL. Bob P. S. With the attached file "n3ms.lisp" in place, one can execute sbcl --dynamic-space-size 3200 (push :msa-threads *features*) (load "n3ms.lisp") (our-time (long-test-msa)) The bottom line: long-test-msa: ratio of real stable-sort/msa times: 2.3011072 |
From: steve g. <sgo...@gm...> - 2024-02-14 18:48:38
|
On 2/5/24 02:17, Robert Boyer wrote: > The 50 lines of text below are the first 50 lines of the attached file. > > Thanks, > > Bob > > > #| > Here is a demonstration of a possible bug in the SBCL garbage collector. > 1. I start up sbcl on my $100 Lenovo Chromebook, which gives me the > banner: > > This is SBCL 2.1.1.debian, an implementation of ANSI Common Lisp. > > 2. I load this file with: > > (load "sbcl-gc-problem.lisp") > > 3. I execute this form: > > (time (null (merge-sort (make-array 17000000)))) > > which takes about 12 seconds. > 4. Then I execute the same form again and I get the following crash > report. I [...] if you are using bash try using ulimit at the console steve@fedora:~$ ulimit -a real-time non-blocking time (microseconds, -R) unlimited core file size (blocks, -c) 8096 data seg size (kbytes, -d) unlimited scheduling priority (-e) 0 file size (blocks, -f) unlimited pending signals (-i) 63008 max locked memory (kbytes, -l) 8192 max memory size (kbytes, -m) unlimited open files (-n) 1024 pipe size (512 bytes, -p) 8 POSIX message queues (bytes, -q) 819200 real-time priority (-r) 0 stack size (kbytes, -s) 8192 cpu time (seconds, -t) unlimited max user processes (-u) 63008 virtual memory (kbytes, -v) unlimited file locks (-x) unlimited steve@fedora:~$ man bash ‘ulimit’ provides control over the resources available to processes started by the shell, on systems that allow such control. If an option is given, it is interpreted as follows: you might want to increase the size of the stack,heap, and of course threads. Also before running the second time try using (room) before (gc). * (room) Dynamic space usage is: 17,008,880 bytes. Immobile space usage is: 12,603,392 bytes (15,536 bytes overhead). Read-only space usage is: 6,655,696 bytes. Static space usage is: 3,424 bytes. Control stack usage is: 2,112 bytes. Binding stack usage is: 640 bytes. Control and binding stack usage is for the current thread only. Garbage collection is currently enabled. Breakdown for dynamic space: 6,901,680 bytes for 105,895 instance objects 5,354,080 bytes for 23,058 simple-vector objects 3,914,192 bytes for 244,637 cons objects 828,816 bytes for 18,076 other objects 16,998,768 bytes for 391,666 dynamic objects (space total) Breakdown for immobile space: 10,751,232 bytes for 17,388 code objects 1,258,896 bytes for 26,227 symbol objects 577,728 bytes for 16,078 other objects 12,587,856 bytes for 59,693 immobile objects (space total) * (gc) ;; just to be sure > rob...@gm... > > Heap exhausted during allocation: 10616832 bytes available, 34000016 > requested. > Total bytes allocated = 954515152 > Dynamic-space-size bytes = 1073741824 > GC control variables: > *GC-INHIBIT* = false > *GC-PENDING* = true > *STOP-FOR-GC-PENDING* = false > > debugger invoked on a SB-KERNEL::HEAP-EXHAUSTED-ERROR in thread > #<THREAD "main thread" RUNNING {1001880173}>: > Heap exhausted (no more space for allocation). > 10616832 bytes available, 34000016 requested. > > PROCEED WITH CAUTION. > > |# > again I would check your shell, ulimit -a and set the options in your login file. this is assuming you have permishion to do so :) otherwise get the IT guys to build the image with more heap space. under linux fedora bash > cat /proc/meminfo for just about anything bash > free -h I hope this helps.. |
From: <li...@qq...> - 2024-02-14 17:00:17
|
Hello SBCL developers, When debugging my application, I have encountered instances where SBCL reports the following error while reading circular objects containing read-evaluated CLOS objects: Unsafe concurrent operations on #<HASH-TABLE :TEST EQL :COUNT 73 {100A014B43}> detected. [Condition of type SIMPLE-ERROR] Restarts: 0: [ABORT] abort thread (#<THREAD tid=416330 "Unknown thread 13" RUNNING {1001468003}>) Backtrace: 0: (SB-IMPL::SIGNAL-CORRUPT-HASH-TABLE #<HASH-TABLE :TEST EQL :COUNT 73 {100A014B43}>) 1: (SB-IMPL::GROW-HASH-TABLE #<HASH-TABLE :TEST EQL :COUNT 73 {100A014B43}>) 2: ((FLET SB-IMPL::INSERT-AT :IN "SYS:SRC;CODE;TARGET-HASH-TABLE.LISP") #<unavailable argument> #<HASH-TABLE :TEST EQL :COUNT 73 {100A014B43}> (POKEMON-EONIAN-EMERALD.CORE.OVERWORLD:JUMP :DISTANCE 1.0 :D.. 3: (SB-IMPL::PUTHASH/EQL #<unavailable argument> #<unavailable argument> #<unavailable argument>) 4: ((FLET "WITHOUT-INTERRUPTS-BODY-22" :IN SB-THREAD::CALL-WITH-RECURSIVE-SYSTEM-LOCK)) 5: (SB-THREAD::CALL-WITH-RECURSIVE-SYSTEM-LOCK #<FUNCTION (FLET SB-THREAD::RECURSIVE-SYSTEM-LOCK-THUNK :IN SB-IMPL::PICK-TABLE-METHODS) {7FCF8FD7DD7B}> #<SB-THREAD:MUTEX "hash-table lock" taken owner=Unk.. 6: (SB-IMPL::PUTHASH/EQL/LOCK #<unavailable argument> #<unavailable argument> #<unavailable argument>) After debugging, I discovered that when SBCL reads objects that potentially contain circular references, it adds the values of all slots, including unbound slots in CLOS objects, to the xset. When #<unbound> is used as a key in a hashtable, it leads to internal state corruption in the hashtable. The problematic scenario can be simplified as follows: (unlock-package '#:sb-kernel) (in-package #:sb-kernel) (defun add-to-xset (elt xset) (print elt) ; We print ELT for debugging purpose. (let ((data (xset-data xset))) (if (listp data) (let ((size (xset-extra xset))) (if (< size +xset-list-size-limit+) (unless (member elt data :test #'eql) (setf (xset-extra xset) (1+ size) (xset-data xset) (cons elt data))) (let ((table (make-hash-table :size (* 2 size) :test #'eql :synchronized t))) (setf (gethash elt table) t) (dolist (x data) (setf (gethash x table) t)) (setf (xset-extra xset) 0 ; looks nice to clear it (xset-data xset) table)))) (setf (gethash elt data) t)))) (in-package #:cl-user) (defstruct foo a b c) (defclass bar () (a b c)) (read-from-string "#1=#S(FOO :A #.(MAKE-INSTANCE 'BAR))") Executing the above code will result in printing #<unbound>, which indicates that xset may be corrupted. Thank you in advance for your attention to and resolution of this issue. Best regards, bohonghuang |
From: Robert B. <rob...@gm...> - 2024-02-13 18:35:59
|
In the file nnms.lisp, the comment for msa, which I hope is exactly the same as for stable-sort, contains something unusual, to wit a 'formal specification' of the function. It is great that the specification is also executable. Cf. the attached file check.lisp. It is conceivable that I am wrong about what 'stable' actually means. SBCL is wonderful. Bob |
From: Robert B. <rob...@gm...> - 2024-02-13 17:53:32
|
If you try to load in the two forms right at the top of https://drive.google.com/file/d/1_Ale3T2ImujvvgsjbL0foyU3PZ-ZJ9LS/view?usp=drive_link the evaluation of the second bombs out on my $100 Lenovo Chromebook with the wonderful message 'Killed'. Not too useful of an error message. If you start with sbcl --dynamic-space-size 3200, you can load either form ok. My guess is that this may be some sort of strange virtual memory bug. sbcl is wonderful. Bob |
From: Douglas K. <do...@go...> - 2024-02-13 15:22:04
|
This is https://bugs.launchpad.net/sbcl/+bug/308936. The fact that this bug entry was opened 16 years ago (by an SBCL developer) mainly as a theoretical observation, and has not been vocally complained about to my knowledge, suggests that there isn't a huge demand for a fix. That, and the cost of a fix being quite high in terms of impact upon the Lisp reader, suggests that you should probably not rely on READ to do complicated circular deserialization of typed objects. Perhaps you could read into temporary graph structures built of symbols and conses, and then patch in actual objects. There are some libraries that do this, I think. On Tue, Feb 13, 2024 at 9:44 AM lisexp via Sbcl-bugs < sbc...@li...> wrote: > Dear SBCL Developers, > > I am trying to use SBCL's writer/reader as a simple > serialization/deserialization tool in my application, but I found that > the reader fails in the following simple case: > > (defstruct list-cons > (car nil :type t) > (cdr nil :type (or list-cons null))) > > (read-from-string "#1=#S(LIST-CONS :CAR 1 :CDR #1#)") > > SBCL reports: > > The value > #S(SB-IMPL::SHARP-EQUAL-WRAPPER > :LABEL 1 > :VALUE SB-IMPL::+SHARP-EQUAL-MARKER+) > > is not of type > (OR COMMON-LISP-USER::LIST-CONS NULL) > when setting slot CDR of structure LIST-CONS > [Condition of type TYPE-ERROR] > > > This seems to be related to SBCL's strict type checking? It works fine > when tested on CCL and CLISP. Thank you in advance for your attention > to this issue. > > Best regards, > > bohonghuang > _______________________________________________ > Sbcl-bugs mailing list > Sbc...@li... > https://lists.sourceforge.net/lists/listinfo/sbcl-bugs > |
From: <li...@qq...> - 2024-02-13 14:44:10
|
Dear SBCL Developers, I am trying to use SBCL's writer/reader as a simple serialization/deserialization tool in my application, but I found that the reader fails in the following simple case: (defstruct list-cons (car nil :type t) (cdr nil :type (or list-cons null))) (read-from-string "#1=#S(LIST-CONS :CAR 1 :CDR #1#)") SBCL reports: The value #S(SB-IMPL::SHARP-EQUAL-WRAPPER :LABEL 1 :VALUE SB-IMPL::+SHARP-EQUAL-MARKER+) is not of type (OR COMMON-LISP-USER::LIST-CONS NULL) when setting slot CDR of structure LIST-CONS [Condition of type TYPE-ERROR] This seems to be related to SBCL's strict type checking? It works fine when tested on CCL and CLISP. Thank you in advance for your attention to this issue. Best regards, bohonghuang |
From: <don...@is...> - 2024-02-09 17:37:26
|
> > > i did notice that if you remove the form which defines the parameter, > > the problem did not occur. I have NOT noticed that. In fact if I do defvar once and setf in the loop I still get the heap exhaustion. And this is still true in * (lisp-implementation-version) "2.4.1.123-37358cdb1" Perhaps (gc :full t) should be done before asking for more space than is available? Perhaps even before that. |