freenode/#clasp - IRC Chatlog
Search
14:24:36
kpoeck
Drmeister why did you change in load.cc the outputs for :verbose and :print to BFORMAT_T (initially eval::funcall(cl::_sym_format ....)
14:27:45
kpoeck
Can I change that back to eval::funcall, so that some ansi-tests that capture output from load work again?
14:31:12
drmeister
Ok, so I changed from my old, weird _lisp->print(...) to BFORMAT_T because BFORMAT_T prints properly to the standard output.
14:32:21
kpoeck
to eval::funcall(cl::_sym_format, _lisp->_true(), SimpleBaseString_O::make("~&;;; Loading ~s~%"), lsource);
14:33:26
drmeister
Right - but that may have trouble or at least look weird in the interpreter or aclasp - because format isn't fully installed at that point.
14:34:18
drmeister
The interpreter provides a seriously crippled version of format and only bclasp contains the proper version implemented in Common Lisp.
14:36:56
kpoeck
In compile-file there is describe-form using only write-string and terpri, is that bootstrap safe?
14:37:17
drmeister
What I mean to say is "yes", we can change it to eval::funcall(cl::_sym_format,...) to make it work properly.
14:37:43
drmeister
I'm just messing more with the interpreter and aclasp and it would be nice to have load print stuff properly in there as well.
14:39:51
kpoeck
Is there something like if (format-already-works) eval::funcalll .... else bformat();?
14:39:54
drmeister
If you can do it with write-string and terpri - then do that. If it has a problem - it's easier to back port a solution to the interpreter
14:41:54
drmeister
It writes out to *standard-output* - isn't that all that matters for load printing messages for :verbose and :print?
14:42:40
kpoeck
well and that (with-output-to-string (*standard-output*)(load ...)) captures the output
14:43:35
drmeister
Ah - so the output from BFORMAT_T doesn't get captured by (with-output-to-string (*standard-output*) ...) - that's not good.
14:47:32
drmeister
Ah - I see - that's the central problem. I use BFORMAT_T and BFORMAT a lot in the C++ code because I wanted something like format that worked right from the beginning - but it's not working right.
14:52:01
kpoeck
ok is #define BFORMAT_T(fmt) core::core__bformat(_lisp->_true(),(fmt).str(),_Nil<core::T_O>());
14:54:34
kpoeck
(with-output-to-string (*standard-output*)(core:bformat *standard-output* "Foo")) -> "Foo"
14:54:56
drmeister
It's not working properly (with-output-to-string (*standard-output*) (bformat t "whatever")) should return a string containing "whatever"
14:55:16
kpoeck
and (with-output-to-string (*standard-output*)(core:bformat *standard-output* "Foo")) works
14:56:57
drmeister
Yeah - if you pass T to it you get cl::*terminal-io* rather than cl::*standard-output*
15:00:15
Bike
it shouldn't be hard. destination can be T, NIL, a string with a fill pointer, or a stream. T means standard output, nil means write to string, a string means put it on the end, and a stream is itself;.
15:02:23
Bike
we handle it fine for actual format https://github.com/clasp-developers/clasp/blob/master/src/lisp/kernel/lsp/format.lsp#L505-L517
15:02:41
kpoeck
Bike, do you say that changing outputStreamDesignator to return *standard-output* instead of *terminal-io* is wrong?
15:03:40
Bike
if bformat is supposed to mimic format, it shouldn't be using an output stream designator.
15:05:02
kpoeck
http://www.lispworks.com/documentation/HyperSpec/Body/26_glo_s.htm#stream_designator ?
15:06:16
kpoeck
nil (denoting the value of *standard-input* for input stream designators or denoting the value of *standard-output* for output stream designators)
15:07:49
drmeister
NIL converts to my_thread->_BFormatStringOutputStream - a thread local string-output-stream ... for speed.
15:08:00
kpoeck
yes, but than I would expect (with-output-to-string (*standard-output*)(core:bformat nil "Foo")) to return "Foo"
15:09:04
Bike
bformat returns the wrong thing, i guess? it has nothing to do with outputStreamDesignator though.
15:10:41
drmeister
Something else must be wrong kpoeck - I'll compile the change above and then see what's going on.
15:12:55
drmeister
I'm seeing at least two bugs - I'll fixed one - it's compiling - and then i'll take a look at the next one.
15:14:37
kpoeck
I have written some regression to test to verify correct behaviour, so I am prepared to test :-)
15:18:45
drmeister
Right - it would be more consistent with the rest of the code to keep using BFORMAT
15:24:13
Bike
as far as those go, i looked at https://github.com/clasp-developers/clasp/issues/522 but i'm a bit stumped
15:25:02
Bike
i don't see anything that actually alters the fill pointer, so i think it's maybe returning the underlying data vector, or something
15:31:54
drmeister
There's no second bug: (with-output-to-string (*standard-output*) (format nil "Hello")) --> "" is correct.
15:35:49
karlosz
is there a way to invoke partial inlining without the liveness analysis? i do my own dead code elimination later - i feel like the liveness computation outweighs any gains in not analyzing dead variables
15:41:10
drmeister
(with-output-to-string (*standard-output*) (format nil "Hello")) --> "" - there is no output being written to *standard-output* so the form returns an empty string.
15:50:13
Bike
oh, and as long as you're looking at aref stuff... is that TEMPLATED_HALF_STRING whatever stuff actually helpful? does more type tests, i guess, and ends upw ith a specialized function...?
15:55:11
drmeister
nsvector.asAbstractSimpleVectorRange(bsv,start,end) fills bsv, start, end with the backing simple vector, the start in the bsv and the end in the bsv.
15:55:34
drmeister
Then it's doing the nreverse on that. I think I can just return the original non-simple vector
16:05:18
drmeister
Oh yeah - its to deal with all the combinations of SimpleString, SimpleBaseString, Str8Ns, StrWNs
16:05:41
Bike
is it required, though? the general equalp method just worries about simple versus mdarray
16:07:51
drmeister
You could do everything with a general equalp - but there will be type checking when comparing every character - bleh.
16:08:21
drmeister
I wanted to check the types outside of the loop and then have specialized loops for every combination.
16:08:30
Bike
i feel like for equal and string= and stuff we might be able to swing memcmp, but i'm not 100% sure how the characters are stored in the arrays
16:11:01
drmeister
There are 8bit characters and 32 bit characters - we don't want tests in the hot loops
16:12:00
drmeister
The functions that do the actual comparisons are template functions - so you could specialize them for the base-char/base-char pair with memcmp
16:13:00
drmeister
But the base-char/character and character/base-char case - you can't - of course.
16:51:00
drmeister
::notify kpoeck I fixed the bformat problem - is there an issue that deals with (with-output-to-string (*standard-output*) (load ...)) or issues that would be effected by this that we can reevaluate if they can be closed?
16:57:18
kpoeck
Drmeister: I defined regression tests regarding the (with-output-to-string (... (load)) and (with-output-to-string (... (compile-file ))) so I can easily retest
16:57:18
Colleen
kpoeck: drmeister said 6 minutes, 18 seconds ago: I fixed the bformat problem - is there an issue that deals with (with-output-to-string (*standard-output*) (load ...)) or issues that would be effected by this that we can reevaluate if they can be closed?
17:16:52
drmeister
kpoeck: I accepted all of your pull requests except one - you had a question in a comment about using strtof rather than strtod - I think you are correct and asked if you could go a bit further and make the change to use strtof.
17:34:08
nivpgir
remember me as that guy that couldn't build clasp 2 days ago? any chance someone here is willing to look at my errors now?
17:37:23
nivpgir
File "/home/nivpgir/gits/clasp/.waf3-2.0.6-bca992597e6f087c1b15baec6344c36f/waflib/Scripting.py", line 118, in waf_entry_point
17:37:23
nivpgir
File "/home/nivpgir/gits/clasp/.waf3-2.0.6-bca992597e6f087c1b15baec6344c36f/waflib/Scripting.py", line 178, in run_commands
17:37:27
nivpgir
File "/home/nivpgir/gits/clasp/.waf3-2.0.6-bca992597e6f087c1b15baec6344c36f/waflib/Scripting.py", line 169, in run_command
17:37:32
nivpgir
File "/home/nivpgir/gits/clasp/.waf3-2.0.6-bca992597e6f087c1b15baec6344c36f/waflib/Scripting.py", line 366, in execute
17:37:36
nivpgir
File "/home/nivpgir/gits/clasp/.waf3-2.0.6-bca992597e6f087c1b15baec6344c36f/waflib/Build.py", line 93, in execute
17:37:40
nivpgir
File "/home/nivpgir/gits/clasp/.waf3-2.0.6-bca992597e6f087c1b15baec6344c36f/waflib/Build.py", line 100, in execute_build
17:37:47
nivpgir
File "/home/nivpgir/gits/clasp/.waf3-2.0.6-bca992597e6f087c1b15baec6344c36f/waflib/Tools/errcheck.py", line 140, in check_compile
17:37:51
nivpgir
File "/home/nivpgir/gits/clasp/.waf3-2.0.6-bca992597e6f087c1b15baec6344c36f/waflib/Build.py", line 176, in compile
17:37:56
nivpgir
File "/home/nivpgir/gits/clasp/.waf3-2.0.6-bca992597e6f087c1b15baec6344c36f/waflib/Errors.py", line 26, in __init__
17:38:07
nivpgir
{task 139637121536632: link_fasl boehm-fastgf-cxx.a,boehm-builtins-cxx.a,boehm-intrinsics-cxx.a,start.o,prologue.o,min-start.o,init.o,after-init.o,runtime-info.o,jit-setup.o,clsymbols.o,packages.o,foundation.o,export.o,defmacro.o,helpfile.o,evalmacros.o,claspmacros.o,source-transformations.o,arraylib.o,setf.o,listlib.o,mislib.o,defstruct.o,predlib.o,cdr-5.o,seq.o,cmuutil.o,seqmacros.o,seqlib.o,iolib.o,sharpmacros.o,backtrace.o,trace.o,
17:38:09
nivpgir
cmpexports.o,cmpsetup.o,cmpglobals.o,cmputil.o,cmpintrinsics.o,primitives.o,cmpir.o,cmpeh.o,debuginfo.o,codegen-vars.o,arguments.o,cmplambda.o,cmprunall.o,cmpliteral.o,typeq.o,codegen-special-form.o,codegen.o,compile.o,codegen-toplevel.o,compile-file.o,disassemble.o,external-clang.o,cmpname.o,cmpbundle.o,cmprepl.o,min-pre-epilogue.o,epilogue-aclasp.o,min-end.o -> aclasp-boehm-image.fasl}
17:38:20
nivpgir
File '/home/nivpgir/gits/clasp/.waf3-2.0.6-bca992597e6f087c1b15baec6344c36f/waflib/Scripting.py', line 130, in waf_entry_point
17:39:51
nivpgir
yeah, I'm sorry... I'm new to IRC, I didn't predict it would come out like this ...
17:41:31
Bike
"requires dynamic R_X86_64_PC32 reloc against '_ZZN5boost13serialization16singleton_module8get_lockEvE4lock' which may overflow at runtime; recompile with -fPIC". well, that's new to me
17:54:14
drmeister
Because I think there is an incompatibility between the boost library and what Clasp expects or what boost expects or something.
17:56:32
drmeister
Although there may be an issue on the Clasp side - clasp is looking for a static version of the boost library - that may not be a good idea.
17:57:26
drmeister
With waf you either look for the static library or the dynamic library. My understanding is that I have to hard code the search in the wscript file.
17:58:41
drmeister
I started with static libraries for everything because I want to run this on supercomputers that require static linking. I should probably make it switchable with an option.
17:59:19
drmeister
I'm going to try that - I'll add an option and make the default dynamic libraries.
17:59:42
drmeister
We haven't had a test case like this for a while - are you working on this for the next couple of hours - could you work with me to resolve this?
18:01:03
drmeister
Then I'll push - then if you could try it and report back - that would be very helpful.
18:05:05
drmeister
No, it's ok - there are two places that need to be changed. I'm also pretty sure we should link boost dynamically in most cases.
18:12:47
drmeister
If there were a problem in array.h then I should have seen it as well - mine is building fine [63/190]
18:13:19
nivpgir
oh, no, I didn't, I was hoping it's not necessary cause if I do it's gonna take hours