Trying to understand how to fix this new warning that I get when I knit a .qmd file, running the same tbl_regression command that I have done previously without issue.
lm(y ~ x, data = dat) |>
tbl_regression(intercept = T) |>
add_glance_source_note() |>
as_flex_table() |>
flextable::font(fontname = "Consolas", part = "all")
Usage of empty symbol '' with footnote should not happen, use `add_footer_lines()` instead, it does not require any symbol. This usage will be forbidden in the next release. Please, wait for 10 seconds!
How do I keep the glance source note without the warning showing?
Related
I've been trying to wrap my head around this, I've written four functions that I expect should run the same, I'm curious why they're different.
toEffect :: Tuple Int String -> Effect Unit
toEffect (Tuple i strng) =
log $ append (show i <> ": ") $
statefulPuzzleToString $
selectFirstLadderBruteForce $
parsePuzzle strng
main1 :: Effect Unit
main1 = (toEffect $ Tuple 1 $ fromMaybe "" $ hardestBoardStringsX11 !! 0) >>=
(\_ -> toEffect $ Tuple 2 $ fromMaybe "" $ hardestBoardStringsX11 !! 1) >>=
(\_ -> toEffect $ Tuple 3 $ fromMaybe "" $ hardestBoardStringsX11 !! 2) >>=
(\_ -> toEffect $ Tuple 4 $ fromMaybe "" $ hardestBoardStringsX11 !! 3)
-- ... Pattern could continue for all 11 boards
main2 :: Effect Unit
main2 = do
toEffect $ Tuple 1 $ fromMaybe "" $ hardestBoardStringsX11 !! 0
toEffect $ Tuple 2 $ fromMaybe "" $ hardestBoardStringsX11 !! 1
toEffect $ Tuple 3 $ fromMaybe "" $ hardestBoardStringsX11 !! 2
toEffect $ Tuple 4 $ fromMaybe "" $ hardestBoardStringsX11 !! 3
-- ... Pattern could continue for all 11 boards
main3 :: Effect Unit
main3 = foldl
(\acc new -> acc >>= \_ -> new)
(pure unit)
effects
where
effects :: Array (Effect Unit)
effects = map toEffect $ mapWithIndex Tuple hardestBoardStringsX11
main4 :: Effect Unit
main4 = traverse_ toEffect $ mapWithIndex Tuple hardestBoardStringsX11
For the first two, the console appears to display each effect as it happens. There's maybe upwards of a 1/2second delay between log statements. I'd be extremely surprised to see these behave differently as I understand that the do notation in main2 is just syntactic sugar for what was written in main1
The second two appear log their statements simultaneously.
I'm not entirely certain about main4, but I feel pretty confident that main3 really aught to behave the same as the first two.
Any insight into what's happening here?
Both main3 and main4 behave that way for the same reason, and the reason is the difference between evaluation and execution.
When you have a value of type Effect a, which represents some effect that produces a, presumably you got that value from somewhere. Let's say:
myEffect = makeMeAnEffect "foo"
This value has been evaluated inside makeMeAnEffect, but hasn't yet been executed. Here, "evaluation" means making whatever computation is necessary to produce a value of type Effect a. Creating this value may involve some computation - e.g. multiplying numbers, traversing strings, adding matrices. That's all "evaluation".
But the result of evaluation is a "description" of what should happen when the effect is executed. Here "execution" means "running" the effect, making happen whatever action it describes.
Evaluation and execution are technically separate concepts. Many languages conflate them, but pure functional languages, such as PureScript and Haskell, maintain a strict separation: first you create the description of what should happen ("evaluation"), and then "run" that description ("execution").
This distinction is very important in practice: "evaluation" is pure, which means it's completely unobservable except for its result, and so the compiler can do whatever it wants with it - e.g. optimize, roll/unroll, or even completely drop, - as long as its result stays the same. "Execution", on the other hand, has to be carried out in the exact way that the programmer has specified it, because its whole point is to produce effects, so messing with it will have observable consequences.
In your particular case, in the body of toEffect, evaluation is everything that happens after log $. All those calls to append, selectFirstLadderBruteForce, and so on, - all of that is "evaluation". None of that is effectful. You're performing some computation in order to figure out what sort of effect you're going to create.
And then, once you did all that computation, you pass the result of it to log, and that makes you an Effect Unit, which is a "description of what should happen". And in this particular case, "what should happen" is very small - just write a single string to the console.
And now, finally, we can get to the difference between main1/main2 and main3/main4.
In main1 and main2, you're creating each next effect only after the first one has been executed. So evaluation and execution "overlap", so to speak: first you do fist evaluation, create fist effect, then you run it, and then, only after it's done running, you move on to doing the second evaluation and creating the second effect. And so on. Since the expensive part (in your case) is evaluation, each next execution ends up delayed by however much time the next evaluation takes.
In main3 and main4, on the other hand, you do evaluation first, creating all effects at once by calling map toEffect on an array, and only then you proceed to execute them one by one. And since, again, evaluation (in your case) is the expensive part, and all of it is happening at the beginning, the execution is not delayed. Each effect is very small (just print to console), so they all execute very quickly.
If you really want to prevent the next evaluation from happening until the previous execution is done, you can do this trick: add a pure unit at the beginning of toEffect like so:
toEffect (Tuple i strng) = do
pure unit
log $ append (show i <> ": ") $
statefulPuzzleToString $
selectFirstLadderBruteForce $
parsePuzzle strng
This will make sure that the second line doesn't start evaluating until the first line has executed, thus making each evaluation happen only right before its respective execution.
And finally, another fun fact: in Haskell the same program would work differently, because Haskell is lazy. When asked to do an evaluation, it doesn't do it right away, instead just "remembering" that it's been asked to. And only when the evaluation's result is actually necessary (which would happen on execution), will it be performed.
PureScript, on the other hand, is strict, which means it will always compute everything right away. In this particular case, it means it will compute the whole append etc. series of calls before it can pass their result to log.
I would like to run the following q code in python:
table: ("ISI"; enlist ",") 0:`data.csv
I am starting with exploring qpython as its easier to use in Windows for now (compared to pyq) and would like to do the following:
q = qconnection.QConnection(host = 'localhost', port = 5000)
q.sync('table: ("ISI"; enlist ",") 0:`data.csv')
Is something like this possible or do I need to use pyq in the future when its stable for Windows? The examples I have seen for q.sync are queries and functions that take a list of parameters rather than directly running code in the q environment. I would like to make sure I am not missing some other functionality that I can use for my current task.
When trying to access a file you have to use its file handle which is of the form `:data.csv (notice the colon at the start), instead of a symbol which is what you are using. You can use hsym to turn a symbol into a file handle.
You should also check that the file is in the same working directory as the q process, using \dir in the q process on Windows, otherwise you will need to adapt your file handle to point to the correct location
q)hsym `data.csv
`:data.csv
With a file data.csv that has contents:
id,sym,val
1,APPL,50
2,GOOG,100
Running the same command that you did but using the file handle:
In: q.sync('table: ("ISI"; enlist ",") 0: `:data.csv')
or
In: q.sync('table: ("ISI"; enlist ",") 0:hsym `qpython.csv')
Checking the resulting variable using qpython:
In: q.sync('table')
Out: rec.array([(1, b'APPL', 50), (2, b'GOOG', 100)],
dtype=[('id', '<i4'), ('sym', 'S4'), ('val', '<i4')])
Checking in the q process
q)table
id sym val
-----------
1 APPL 50
2 GOOG 100
When i try to evaluate line 2 or 5 of this program, i get "Unbound value carre" or "Unbound value bis".
To evaluate it i use emacs with tuareg, could it be related ?
let carre x = x*x;;
carre(9);;
let bis y = y^y;;
bis("ab");;
For example, here is what i get for line 2 :
# Characters 0-5:
carre(9);;
^^^^^
Error: Unbound value carre
#
The code is very simple so i feel like the problem comes from emacs.
I've tried to change function names, variables names, but nothing worked.
Does anybody see what's wrong here ?
You need to evaluate the first line of your program before the second.
The interpretor doesn't know the definition of carre or bis until you've evaluated it.
When ran in the command line, this
swipl -g "write(42)" -t "halt"
prints 42 to STDOUT as expected.
However, this
swipl -g "X = 42" -t "halt"
does not print anything, it simply returns.
How do I get it to print what it prints in the REPL (that is, X = 42)?
Note: this is in a Windows terminal. Let me know if this actually works in a Linux terminal.
As expected, X = 42 by itself produces no output whatsoever, because (=)/2 is a completely pure predicate that does not yield any side effects by itself. This is the case on Window, OSX and all other operating systems.
Even if there were a way to obtain and redirect the toplevel output itself, the fact remains that the SWI toplevel is subject to change and you cannot rely on future versions to behave in the same way as it does now. Long term, you will likely be better off to roll your own toplevel and produce exactly the output you want.
It is not so hard to roll your own toplevel. The trick is mainly to use the variable_names/1 option when reading terms, so that you can keep track of the variable names that you want to show in answers. Here is a very simplistic start:
repl :-
read_line_to_codes(current_input, Codes),
read_term_from_codes(Codes, Term, [variable_names(NameVars)]),
call(Term),
report_bindings(NameVars).
repl :- repl.
report_bindings(NameVars) :-
phrase(bindings(NameVars), Bs),
format("~s", [Bs]).
bindings([]) --> [].
bindings([E]) --> name_var(E).
bindings([E1,E2|Rest]) --> name_var(E1), ",\n", bindings([E2|Rest]).
name_var(Name=Var) -->
format_("~w = ~q", [Name,Var]).
format_(Format, Ls) -->
call(format_codes(Format, Ls)).
format_codes(Format, Ls, Cs0, Cs) :-
format(codes(Cs0,Cs), Format, Ls).
Example:
?- repl.
|: X = 4, between(1, 3, Y).
X = 4,
Y = 1
true ;
X = 4,
Y = 2
true ;
X = 4,
Y = 3
true ;
|: X = 7.
X = 7
It is easy to modify this so that it works on terms that are specified as arguments.
Note that the variable_names/1 option is essential for reading terms in such a way, and thanks to the ISO standardization effort an increasing number of implementations provide it for read_term/2 and related predicates.
This ability to read variable names is a requirement for implementing a portable Prolog toplevel!
The main exercise that I leave for you is to check if the quoting is right in all cases and (if desired) to produce answers in such a way that they can always be pasted back on the terminal. To extend this to residual constraints, use copy_term/3 and call_residue_vars/2 to collect pending constraints that you can append to the bindings.
I am trying to write a simple server program in Ocaml that communicates with other processes via a socket. I currently have a problem that the strings the server reads (with input_line ic) do not seem to compare with other strings properly. For example, I run the server program and use telnet to connect to it, if I send "end" as a line, the server program trys to match with "end", but this doesn't work as expected. The function that handles communication is service (below), which is called to handle a client as part of a forking server (something like the double fork treatment here).
let service ic oc
try while true do
let instr = input_line ic in
match instr with
| "end" -> print_endline "matching end" (* this never runs *)
| _ -> output_string oc ((String.uppercase instr) ^ "\n") ; flush oc
done
with End_of_file -> print_endline "Input stream ended."
;;
In fact, if I do print_endline (string_of_bool ("end" = instr)) I always get false (even when I send "end" via telnet). To try and get some sense of what is going I printed out the result of different comparison operations between the let-binding and the try block:
print_endline instr ;
print_endline "end" ;
print_endline (string_of_bool ("end" = instr)) ;
print_endline (string_of_bool ("end" == instr)) ;
print_endline (string_of_int (String.compare "end" instr)) ;
When I send "end" the server now prints out
end
end
false
false
-1
I'm really lost as to what could be going on - I presume it must be something about getting the instr via reading from a socket, as usually you can compare strings just fine.
I don't think I actually had a question in all that background so here are a few variants that could work:
What am I doing wrong?
Why can't I test the input in order to take different actions?
Is this a bug in Ocaml?
Do you need the complete source to figure this out?
My guess is that there are carriage returns in the strings coming in from telnet. As I recall, the old protocols tend to send CRLF at the ends of lines.
You might try printing the string out using String.escaped.
It's pretty unlikely you're seeing a bug in OCaml.