How exactly do I require threading macros in Racket?
Following this guide: https://docs.racket-lang.org/threading/index.html I try (require threading) but I get this error:
standard-module-name-resolver: collection not found
for module path: threading
collection: "threading"
in collection directories:
/Users/user/Library/Racket/6.9/collects
/Applications/Racket v6.9/collects
... [163 additional linked and package directories] in: threading
no packages suggestions are available .
Related
I'm trying to write some code that uses Deno and rdflib. And failing miserably.
Here's my test program:
// #deno-types="https://dev.jspm.io/npm:rdflib#2.2.7/lib/index.d.ts"
import { Namespace } from 'https://dev.jspm.io/npm:rdflib#2.2.7/lib/index'
when I ask deno to cache the remote packages, it fails:
$ deno --unstable cache rdflib.ts
Check file:///home/ian/projects/personal/deno-experiments/rdflib.ts
error: TS2502 [ERROR]: 'thisArg' is referenced directly or indirectly in its own type annotation.
bind<T>(this: T, thisArg: ThisParameterType<T>): OmitThisParameter<T>;
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
at asset:///lib.es5.d.ts:350:22
TS2614 [ERROR]: Module '"https://dev.jspm.io/npm:rdflib#2.2.7/lib/query"' has no exported member 'Query'. Did you mean to use 'import Query from "https://dev.jspm.io/npm:rdflib#2.2.7/lib/query"' instead?
import { Query } from './query';
~~~~~
at https://dev.jspm.io/npm:rdflib#2.2.7/lib/index.d.ts:16:10
TS2614 [ERROR]: Module '"https://dev.jspm.io/npm:rdflib#2.2.7/lib/updates-via"' has no exported member 'UpdatesSocket'. Did you mean to use 'import UpdatesSocket from "https://dev.jspm.io/npm:rdflib#2.2.7/lib/updates-via"' instead?
import { UpdatesSocket } from './updates-via';
~~~~~~~~~~~~~
at https://dev.jspm.io/npm:rdflib#2.2.7/lib/index.d.ts:26:10
TS2614 [ERROR]: Module '"https://dev.jspm.io/npm:rdflib#2.2.7/lib/updates-via"' has no exported member 'UpdatesVia'. Did you mean to use 'import UpdatesVia from "https://dev.jspm.io/npm:rdflib#2.2.7/lib/updates-via"' instead?
import { UpdatesVia } from './updates-via';
~~~~~~~~~~
at https://dev.jspm.io/npm:rdflib#2.2.7/lib/index.d.ts:27:10
TS2749 [ERROR]: 'Store' refers to a value, but is being used as a type here. Did you mean 'typeof Store'?
at https://dev.jspm.io/npm:rdflib#2.2.7/lib/index.d.ts:32:32
... many more lines ...
TS2614 [ERROR]: Module '"https://dev.jspm.io/npm:rdflib#2.2.7/lib/utils/termValue"' has no exported member 'termValue'. Did you mean to use 'import termValue from "https://dev.jspm.io/npm:rdflib#2.2.7/lib/utils/termValue"' instead?
export { termValue } from './utils/termValue';
~~~~~~~~~
at https://dev.jspm.io/npm:rdflib#2.2.7/lib/index.d.ts:40:10
Found 44 errors.
As far as I can tell, the problem is with lines in the remote code that do relative imports. Do such relative imports not work with Deno, or am I missing some vital step, or is my approach doomed?
Version info:
$ deno --version
deno 1.12.2 (release, x86_64-unknown-linux-gnu)
v8 9.2.230.14
typescript 4.3.5
The problem is not that they are relative specifiers, but that they are not fully qualified. From section 6.6 in the manual:
Can I use TypeScript not written for Deno?
Maybe. That is the best answer, we are afraid. For lots of reasons, Deno has chosen to have fully qualified module specifiers. In part this is because it treats TypeScript as a first class language. Also, Deno uses explicit module resolution, with no magic. This is effectively the same way browsers themselves work, though they don't obviously support TypeScript directly. If the TypeScript modules use imports that don't have these design decisions in mind, they may not work under Deno.
Also, in recent versions of Deno (starting with 1.5), we have started to use a Rust library to do transformations of TypeScript to JavaScript in certain scenarios. Because of this, there are certain situations in TypeScript where type information is required, and therefore those are not supported under Deno. If you are using tsc as stand-alone, the setting to use is "isolatedModules" and setting it to true to help ensure that your code can be properly handled by Deno.
One of the ways to deal with the extension and the lack of Node.js non-standard resolution logic is to use import maps which would allow you to specify "packages" of bare specifiers which then Deno could resolve and load.
If I evaluate the following in Emacs Cider:
(use 'alembic.still)
(alembic.still/distill '[enlive "1.1.5"])
(require '[net.cgrand.enlive-html :as html])
(html)
... evaluation of the (html) to see if it's a recognized symbol produces an 'Unable to resolve symbol' error. I'm evaluating it via cider connected to a REPL.
How can I use Alembic provided dependencies as an alias?
Your code is not working because html is an alias for a namespace here, not a symbol. The functions from enlive should work, however:
(use 'alembic.still)
(alembic.still/distill '[enlive "1.1.5"])
(require '[net.cgrand.enlive-html :as html])
(html/html-snippet "<div>Hello world</div>")
I'd like to be able to only import namespaced items from a module in Racket. The prefix-in function does allow me to access functions from the module using the prefix, but it doesn't hide the old name.
$ racket
Welcome to Racket v6.6.
> (require (prefix-in tcp: racket/tcp))
> tcp-accept
#<procedure:tcp-accept>
> tcp:tcp-accept
#<procedure:tcp-accept>
Is there a simple way to hide the unprefixed names?
The prefix-in form only imports the prefixed names, not the unprefixed ones. However, the racket language includes the racket/tcp module by default, so it is already imported when the REPL starts up. If you use #lang racket/base, instead, then tcp-accept won’t be imported, so the prefixed import will be the only imported identifier. You can simulate this using the -I racket/base option in the REPL:
$ racket -iI racket/base
Welcome to Racket v6.7.0.4.
> (require (prefix-in tcp: racket/tcp))
> tcp-accept
; tcp-accept: undefined;
; cannot reference undefined identifier
; [,bt for context]
> tcp:tcp-accept
#<procedure:tcp-accept>
I am trying to host XSB in a server. I wrote the following code:
:- module(server, [server/0, server/1]).
:- import http_server/2 from library(http/thread_httpd).
:- import http_dispatch/1 from library(http/http_dispatch).
:- use_module(swish, []).
server :-
server(localhost:3050).
server(Port) :-
http_server(http_dispatch,
[ port(Port),
workers(16)
]).
I am getting the following error
[xsb_configuration loaded]
[sysinitrc loaded]
[xsbbrat loaded]
[Compiling ./server]
++Warning[XSB]: [Compiler] ./server : Unused symbol http_dispatch/1
++Warning[XSB]: [Compiler] ./server : Unused symbol swish/0
++Warning[XSB]: [Compiler] ./server : Unused symbol library(http / http_dispatch)/0
++Error[XSB/Runtime/P]: [Type (library(http / thread_httpd) in place of atom)] in arg 1 of predicate atom_length/2
Forward Continuation...
... asmpass2:asm_putsym/2
Can someone please tell me what I doing wrong here. Your help is greatly appreciated.
You cannot use SWI-Prolog HTTP libraries with XSB. Those libraries rely on SWI-Prolog proprietary features and will not work as-is in XSB. Porting the libraries is not a trivial task either, starting with the fact the module system in SWI-Prolog is predicate-based while the module system in XSB is atom-based.
I'm trying to understand how the Postgres 9.1 rpms are built on CentOS/RHEL 6, so I'm taking a look at the spec file from the source rpms.
What does the following syntax do/mean? Specifically, the question mark and exclamation point?
%{!?test:%define test 1}
%{!?plpython:%define plpython 1}
%{!?pltcl:%define pltcl 1}
%{!?plperl:%define plperl 1}
%{!?ssl:%define ssl 1}
%{!?intdatetimes:%define intdatetimes 1}
%{!?kerberos:%define kerberos 1}
%{!?nls:%define nls 1}
%{!?xml:%define xml 1}
%{!?pam:%define pam 1}
%{!?disablepgfts:%define disablepgfts 0}
%{!?runselftest:%define runselftest 0}
%{!?uuid:%define uuid 1}
%{!?ldap:%define ldap 1
I understand you can define a macro variable with %define <name>[(opts)] <value>, and I believe the exclamation mark is a logical negation operator. I can't find any info on the question mark or examples like the above though. Seems like some sort of test before defining the macro variable.
Here is a paste of the spec file.
Lets review a single item here:
%{!?plpython:%define plpython 1}
On line 102 we also see this:
%if %plpython
BuildRequires: python-devel
%endif
As you said, we know that this is a macro, that can also be confirmed via the Fedora docs. Now if we expand on our search into the Fedora documentation we find conditional macros. This states the following:
You can use a special syntax to test for the existence of macros. For example:
%{?macro_to_test: expression}
This syntax tells RPM to expand the expression if macro_to_test exists, otherwise ignore. A leading exclamation point, !, tests for the non-existence of a macro:
%{!?macro_to_test: expression}
In this example, if the macro_to_test macro does not exist, then expand the expression.
The Fedora docs have provided the answer, if the plpython macro doesn't exist, then
%define plython 1
If you look at line 38 you can also see this:
# In this file you can find the default build package list macros. These can be overridden by defining
# on the rpm command line:
# rpm --define 'packagename 1' .... to force the package to build.
# rpm --define 'packagename 0' .... to force the package NOT to build.
# The base package, the lib package, the devel package, and the server package always get built.
So if you don't define the the macro when you build the package (I imagine this is what most users would do) it's going to ensure that the buildrequires are properly configured for what appears to be a standard PostgreSQL installation.