I am learning Yesod and was looking for postgresql usage examples in ghci when I ran into this
How to perform database queries in GHCi in Yesod Application
pcon <- openSimpleConn con
The package has changed since this answer was given and now openSimpleConn requires a LogFunc in addition to the Connection string. Reading the docs for openSimpleConn and LogFunc does not yield any examples regarding where to get a LogFunc or how to use one (I am still new to Haskell)
Assuming it wants some kind of logging function, I tried doing
pcon <- openSimpleConn runStdoutLoggingT con
But this was met with
<interactive>:22:9: Not in scope: ‘runStdoutLoggingT’
At which point I decided I needed some help.
So, my questions are, what is a LogFunc and what is the proper way to get and use one?
The simplest implementation you can use it \_ _ _ _ -> return (), i.e., ignore all arguments and do nothing. For more details on what's going on, check out the monad-logger package.
Related
When using AssertJ, can I avoid casting when testing a Supplier of Streams?
I tried looking at open issues and most point to https://github.com/joel-costigliola/assertj-core/issues/683 but I don't think it is a direct match.
Supplier<Stream<String>> supplier =
() -> Stream.of("String1", "String2");
assertThat(supplier).isNotNull()
.extracting(Supplier::get)
.isInstanceOf(Stream.class)
.satisfies((stream) ->
assertThat((Stream)stream)
.contains("String1", "String2"));
The test works but I would like to avoid the casting of the Stream if possible.
Thanks.
I agree with tkruse comment!
I just want to add that in AssertJ Core next version (3.13.0), you will be able to use asInstanceOf to cast the object under test and access type specific assertion, see https://github.com/joel-costigliola/assertj-core/pull/1498
Object value = 0;
assertThat(values).asInstanceOf(INTEGER).isZero();
In your case, I believe you would be able to write:
assertThat(supplier).isNotNull()
.extracting(Supplier::get)
.asInstanceOf(STREAM)
.satisfies(stream -> assertThat(stream).contains("String1",
"String2"));
I don't quite understand why this is not failing:
def hello(name: str) -> int:
ending:int = '!!!'
return f'Hello {name} {ending}'
print(hello('John')) # Hello John !!!
And if there is already possibility to strong type python?
The reason is explained in PEP 484 by Guido himself:
It should also be emphasized that Python will remain a dynamically typed language, and the authors have no desire to ever make type hints mandatory, even by convention.
So the answer is NO. Type hints are only hints. They help to indicate what type of data a variable or function should/may contain/returns/etc. It wasn't designed to transform Python into a statically typed language.
As I wrote in comment it is nice to use mypy myproject.py to run it before project/code run. Then you could verify data types structure and correct flow.
I'm learning Reasonml, and I can't find any function in the standard library to do so, neither of the Bucklescript Js modules. Is there any better option than using raw javascript?
Right now I'm achieving it with this function:
let parseint: string => int = [%raw {| x => parseInt(x, 10) |}];
int_of_string (and also float_of_string / bool_of_string) should do what you need.
It's in the standard lib, you should be able to search for it https://caml.inria.fr/pub/docs/manual-ocaml/libref/Pervasives.html (that site will work better for you if you have the reason-tools browser extension installed so it auto-converts from OCaml to Reason syntax for you)
Note that all of those functions will throw an exception if the string isn't valid for that type (read the link to see how each works and what each expects for the string).
As #glennsl points out, when Bucklescript catches up with a more recent version of the OCaml compiler than 4.02.3, you may want to use the safer _opt variants, e.g. int_of_string_opt that returns a Some(number) or None instead, depending on how much you trust the input, how much you want to avoid exceptions, and how you want to deal with bad input (is it exceptional and should kill the program/stack, or is it normal and should be handled locally?).
I see this type of pattern (found this example here) quite often in Scala:
class UserActor extends Actor {
def receive = {
case GetUser(id) =>
// load the user, reply with None or Some(user)
val user: Option[User] = ...
sender ! user
case FindAll() =>
// find all users
val users: List[User] = ...
sender ! users
case Save(user) =>
// persist the user
sender ! Right(user)
}
}
So depending on the call you get: Option[User], List[User], Right[User]. This approach is fine! I'm just asking out of interest if this is optimal? For example (and this may be a bad one): Will it make API's better or worse to try and generalise by always returning List[User]? So when a user is not found or if a save fails, then the list will simply be empty. I'm just curious.... any other suggestions on how the above 'pattern' may be improved?
I'm just trying to identify a perfect pattern for this style of API where you sometimes get one entity and sometimes none and sometimes a list of them. Is there a 'best' way to do this, or does everyone role their own?
The return types should help clarify your API's intended behavior.
If GetUser returned a List, developers might get confused and wonder if multiple users could possibly be returned. When they see that an Option is returned, they will immediately understand the intended behavior.
I once had to work with a fairly complex API which provided CRUD operations that had been generalized in the manner you describe. I found it to be difficult to understand, vaguely defined, and hard to work with.
In my opinion it is a very good pattern for API design.
I use very often Option as return type of my functions, if I want to return a single element, obviously because I don't need to deal with null. Returning a Seq is naturally for multiple elements and Either is optimal if you want to return a failure-description, I use it often while parsing I/O. Sometimes I even combine the Seq with one of the others. You likely don't know the preferences and goals of an user of your API, so it makes sence to provide all of these return-types to make the user feel as comfortable as possible.
I'm currently experimenting with using OCaml and GTK together (using the lablgtk bindings). However, the documentation isn't the best, and while I can work out how to use most of the features, I'm stuck with changing notebook pages (switching to a different tab).
I have found the function that I need to use, but I don't know how to use it. The documentation seems to suggest that it is in a sub-module of GtkPackProps.Notebook, but I don't know how to call this.
Also, this function has a type signature different to any I have seen before.
val switch_page : ([> `notebook ], Gpointer.boxed option -> int -> unit) GtkSignal.t
I think it returns a GtkSignal.t, but I have no idea how to pass the first parameter to the function (the whole part in brackets).
Has anyone got some sample code showing how to change the notebook page, or can perhaps give me some tips on how to do this?
What you have found is not a function but the signal. The functional type you see in its type is the type of the callback that will be called when the page switch happen, but won't cause it.
by the way the type of switch_page is read as: a signal (GtkSignal.t) raised by notebook [> `notebook ], whose callbacks have type Gpointer.boxed option -> int -> unit
Generally speaking, with lablgtk, you'd better stay away of the Gtk* low level modules, and use tge G[A-Z] higher level module. Those module API look like the C Gtk one, and I always use the main Gtk doc to help myself.
In your case you want to use the GPack.notebook object and its goto_page method.
You've found a polymorphic variant; they're described in the manual in Section 4.2, and the typing rules always break my head. I believe what the signature says is that the function switch_page expects as argument a GtkSignal.t, which is an abstraction parameterized by two types:
The first type parameter,
[> `notebook]
includes as values any polymorphic variant including notebook (that's what the greater-than means).
The second type parameter is an ordinary function.
If I'm reading the documentation for GtkSignal.t correctly, it's not a function at all; it's a record with three fields:
name is a string.
classe is a polymorphic variant which could be ``notebook` or something else.
marshaller is a marshaller for the function type Gpointer.boxed option -> int -> unit.
I hope this helps. If you have more trouble, section 4.2 of the manual, on polymorphic variants, might sort you out.