I have a function I created called ENCODE-JSON-TO-STRING in my package called libray.
I wanted to replace my function with the function from cl-json. Which is also called ENCODE-JSON-TO-STRING.
I removed my function with fmakunbound.
However when I try to import cl-json I get the following error:
LIBRARY also shadows the following symbols:
(JSON:ENCODE-JSON-TO-STRING)
compilation failed
My goal is to completely erase the existance of LIBRARY:ENCODE-JSON-TO-STRING
How do I achieve that?
Package importing looks on symbols, and does not care whether they are bound or fbound or not.
The term to remove symbol from package is unintern, and the function to achieve it has same name - unintern, so what you look for should be (unintern 'LIBRARY:ENCODE-JSON-TO-STRING 'library).
You may also want to have a look on shadowing-import and package concepts in general.
Of course, simplest way may be just simply restart and rebuild your system from clean image without creating LIBRARY:ENCODE-JSON-TO-STRING at all.
Related
I am using TypeScript with React, and one of the things I want to achieve is background sync for offline support.
To enable typings for service worker, I have to include the WebWorker lib, but it conflicts with DOM lib and produces an error:
(25,1): Definitions of the following identifiers conflict with those in another file:
EventListenerOrEventListenerObject, BlobPart, HeadersInit, BodyInit,
RequestInfo, DOMHighResTimeStamp, PerformanceEntryList, PushMessageDataInit,
VibratePattern, BufferSource, DOMTimeStamp, FormDataEntryValue,
IDBValidKey, MessageEventSource, BinaryType, ClientTypes,
IDBCursorDirection, IDBRequestReadyState, IDBTransactionMode,
NotificationDirection, NotificationPermission, PushEncryptionKeyName,
PushPermissionState, ReferrerPolicy, RequestCache, RequestCredentials,
RequestDestination, RequestMode, RequestRedirect, ResponseType,
ServiceWorkerState, ServiceWorkerUpdateViaCache, VisibilityState,
WorkerType, XMLHttpRequestResponseType
So I am wondering if there is any workaround except for typing most of my arguments any.
You can split your project into multiple parts with separate tsconfig.json files: one part that includes the dom lib and one part that includes the webworker lib. You can make another part for common code that doesn't depend on either library. You can use project references to help automate the build. If this doesn't fully solve the problem, please update the question to describe the outstanding issues.
good day!
i have small question about reload c module in tarantool
for example: i have c module which expose a method:
int calculate(lua_State* L);
in addition i declared entry point:
extern "C"
{
LUA_API int luaopen_cuendemodule(lua_State *L);
}
now, i load this module ("testmodule.so") in tarantool:
require('testmodule')
box.schema.func.create('testmodule.calculate')
box.schema.user.grant('user', 'execute', 'function', 'testmodule.calculate')
and now i call this method from my c# client:
await tarantoolClient.Call<TarantoolTuple<CalculateParameters>, CalculationResults>("testmodule.calculate", TarantoolTuple.Create(....));
and it is work as expected - method calculate executed and results was returned
but if i want ะตั update my module than the problems begin: after i replace so file and call calculate method my tarantool restart and i can see something like "tarntool invalid opcode in testmodule.so" in dmesg
after reading documentation i see additional parameters in function definition like this:
box.schema.func.create('testmodule.calculate', {language = 'C'})
but after this if i call it from c# i receive exception with message "failed to dynamically load function undefined symbol calculate"
i use tarantool 1.7 on ubuntu
my so compiled with gcc 8.1.0
There is no a good way to do this (means - a portable way). I think, the best way is using something like dlopen()[1], the function allows to open (manage shared objects in general) a shared object, but you have to be very cautious about this, it may fail your code as well or even you can have sigfault.
A good example is: https://github.com/tarantool/mqtt, the module does not use these functions (func.create and so on), but it could be extended as well.
So the point is: if you develop a C-module, you have to think about reloading policy.
For instance, *-unix like systems have alot of features which allows to reload some shared objects and also tarantool has some features too.
And also, I suggest to you, start think about modules as like about Lua's C-modules, it is actually the same.
PS
Some reload modules also available: https://github.com/Mons/tnt-package-reload (I didn't test the module), https://github.com/tarantool/reload (I didn't test the module)
[1] http://man7.org/linux/man-pages/man3/dlopen.3.html
I think, you can try this module for reload your application -https://github.com/moonlibs/package-reload.
One of the projects I'm collaborating on has four different modules (Foo, Bar, Baz, and Plotting) and I've been tasked with combining them into a package. It is simple enough in Julia to make a new package:
julia> Pkg.generate("MyPackage", "MIT")
I copied my modules into the ~/.julia/v0.3/MyPackage/src/ and added include statements to MyPackage.jl. It looks something like this:
module MyPackage
include("foo.jl")
include("bar.jl")
include("baz.jl")
include("plotting.jl")
end
Each included file contains the corresponding module.
My main problem with this is Plotting takes forever to import and it's not needed very often when we're using the rest of MyPackage. I'd really like to be able to do something like using MyPackage.Foo to just get Foo (and particularly to exclude the Plotting and its slow import time). I've tried a couple different approaches for how I structure things, including having sub-modules explicitly defined inside MyPackage.jl instead of in each file individually, but no matter what I try, I always get the loading lag from Plotting.
Is it possible build a package so you can independently load modules from it? and if so, how?
Note: I'm new to Julia and newer still to building packages. Sorry if any of my semantics are wrong or anything is unclear.
Try Requires.jl:
Requires is a Julia package that will magically make loading packages faster, maybe. It supports specifying glue code in packages which will load automatically when a another package is loaded, so that explicit dependencies (and long load times) can be avoided.
Is it possible build a package so you can independently load modules from it? and if so, how?
Following the advice of this comment has worked for me:
https://discourse.julialang.org/t/multiple-modules-in-single-package/5615/7?u=nhdaly
You can change the top-level package-named Module to simply just expose the other four Modules as follows:
# <julia_home>/MyPackage/src/MyPackage.jl
module MyPackage
push!(LOAD_PATH, #__DIR__) # expose all other modules defined in this directory.
end
Then to import the other modules, say Bar, the user code would do:
# code.jl
using MyPackage; using Foo;
...
But it's worth noting that, then, Foo, Bar, Baz and Plotting are all also treated as top-level modules, so you'll want to make their names unique so they don't conflict with other Packages/Modules. (ie somethig like MyPackageFoo, not Foo.)
I am trying to create an extension to wrap an existing DLL without extensive knowledge of C/++. I have used the sample extension as a base and everything seems to work fine, what I would like to do is have some error handling inside my dll.
Is there a way of sending custom errors back to dart if something inside the dll fails? Would it just be a case of sending lets say an array with the first parameter being a bool as to whether it failed or not and the second parameter being a string for the error if there is one. Or is there an actual way to throw errors from the dll itself?
Hope this made sense,
Thanks,
You should take a look inside dart_api.h file, it contains a lot of comments about Dart native stuff.
I have found Dart_ThrowException function there, but also a comment saying that Dart_NewUnhandledExceptionError should be used instead.
Both functions need a Dart exception object handle. It seems that Dart team uses their own Dart Util library to create them:
Dart_ThrowException(DartUtils::NewDartArgumentError("error message"))
Consider I have large library package with sophisticated tree of private or package modules โ let's call it funnylib. It's not desirable for enduser to touch internal modules directly (like funnylib.foo, funnylib.bar etc), so I want to provide external interface instead โ like this:
funnylib.d:
public import funnylib.foo;
public import funnylib.bar;
public import funnylib.baz;
to be just imported like import funnylib by enduser. The problem is that D disallows having funnylib.d and funnylib/ at the same time.
Is there something like "default package module" in D, like there is __init__.py in Python? If no, what is right way to do design described above?
Update1: I thought about moving iternal modules to package like funnylib_private, so funnylib will import fine, but this will have cost of protection lowering (strongly undesirable), as funnylib will no longer access package protected symbols, and will result in unpleasant file layout.
You cannot have a module and a package with the same name. So, for instance, Phobos couldn't have a std/algorithm.d and a std/algorithm/sorting.d. std/algorithm.d and std/algorithm would conflict. The typical thing to do is what ratchet freak describes and use a module named all which publicly imports all of the modules within that package. But if you want to hide the fact that you're using sub-modules at all, then you could simply do something like
funnylib.d
_funnylib/foo.d
_funnylib/bar.d
_funnylib/baz.d
and not document _funnylib anywhere, but that doesn't work very well with ddoc, because it's going to generate the documentation for each of the _funnylib modules, and the most that it'll generate for funnylib.d is the module documentation, because it doesn't have any symbols to document. The module system is not designed with the idea that you're going to be hiding modules like you're trying to do.
Now, there is currently a proposal under discussion for making it possible to cleanly split up a module into a package when it gets too large (e.g. so that when you split up std.algorithm into std.algorithm.search, std.algorithm.sorting, etc. code which explicitly uses std.algorithm.countUntil won't break even though it's now std.algorithm.search.countUntil). And once that's sorted out, you could use that, but the documentation would still be done for each sub-module, not for your uber-module. It's really meant as a means of transitioning code, not trying to hide the fact that you're splitting up your modules. It's basically just the equivalent of using an all module but with some semantic sugar to avoid breaking code in the case where the package used to be a single module.
create a simple all module with the public imports that is documented to import the library
module funnylib.all;
public import funnylib.foo;
public import funnylib.bar;
public import funnylib.baz;