So, for an embedded project with external NOR flash and existing commercial RTOS.
Can I use the coffee filesystem in a form of a library, i.e. to compile it in? From what I've seen it seems possible, only the dependencies go quite deep in to Contiki. I'll surely dig in, but may be someone have done something of the kind already?
This does look very doable.
From a quick grep in core/cfs/ it looks like there are no Contiki-specific abstractions used in the implementation of CFS. And another very quick search on GitHub shows that swift-nav/piksi_firmware contains and uses CFS without Contiki.
Related
BACKGROUND
One of the very useful tools for reproducible work in R is the "here" library.
https://malco.io/2018/11/05/why-should-i-use-the-here-package-when-i-m-already-using-projects/
http://jenrichmond.rbind.io/post/how-to-use-the-here-package/
https://here.r-lib.org/
https://here.r-lib.org/articles/rmarkdown.html
I was hooked by the part in the first link where they said this:
The "here" library is encoded in Anaconda as "r-here"
I'm not sure which came first, but Python has a "here" library as well.
https://pypi.org/project/pyhere/
https://github.com/wildland-creative/pyhere
"Here" makes relative paths a trivial matter, which is really useful for reproducible data-science and analysis work.
QUESTION
What is the Julia equivalent for clean handling of relative paths for files?
Is there a clean way to integrate that with project packaging, like RStudio does?
Based on the description, it sounds like DrWatson.jl does what you're looking for. From the website:
[DrWatson] is a Julia package created to help people increase the consistency of their scientific projects, navigate them and share them faster and easier, manage scripts, existing simulations as well as project source code. DrWatson helps establishing reproducibility, and in general it makes managing a scientific project a simple job.
Like the description implies, it's more ambitious than here seems to be, having functionality to also manage data, simulation runs, etc. But they're optional, and you can use only the directory handling part if you need.
The Navigating a Project describes the projectdir function which works similar to here. projectdir("foo", "bar") resolves to foo/bar under the current project's root directory, just like with here.
There's also datadir(), srcdir(), and others to directly handle common subdirectories under a project for eg. datadir("foo", "test.jld2") resolves to data/foo/test.jld2 under the project's root directory.
It doesn't exist, as far as I'm aware (Here.jl doesn't return any Google hits), but it seems like it would a simple enough for someone to implement. Maybe you!
I want to write a simple editor with basic autocomplete functionality for the Go language as a pet project. How would one go about doing it? I took a look at the Go plugins for Eclipse and IntelliJ, but they were too big for me to comprehend (not to mention getting one to compile).
The Go standard library offers the building blocks for a Go parser which
you can use to parse the source files and look for function definitions and the like.
There's also the godoc command which
already does what you want: extracting method definitions and it's documentation. You may look in the
source code to see how godoc is
working or use godoc directly.
This editor written in Go projects has a manageable amount of code,
you may look into it.
The de facto standard approach to this problem is to use nsf's gocode. I have tried it only in Vim - it works very well.
Even though there's ready made support for specific editors, gocode is not editor specific. It's a daemon with a communication protocol. It is thus usable from any program.
I want to open libraries, because currently I want to see the algorithms used for drawing, modify them and implement them in my program. For example: I have tried to create an algorithm on my own for lines. But I failed. And even if I had succeeded, I fear that it might not give the same result as the algorithm in the libraries. And I don't want this to happen. That's why I want to copy the algorithms used for the methods in libraries. And I really hope that this will help me create the application I'm currently working on and with other applications in the future.
I tried to open the libraries with a code editor. But I had troubles finding the libraries- I don't really know where are they placed nor in what files are their codes stored.
How to open a Java library? Or is there a place in the Internet where the code is uploaded?
It sounds like what you want is to get inside the standard Java libraries (so you can see the code for methods like Graphics.drawLine()).
You can download the source files from the same place you got the JDK, if you are on Windows or Linux. For the Mac, see this question. You can even set up Eclipse so that you can debug into that source as if it were your own code.
However, you will probably not find line-drawing code in Java in these libraries - the Graphics implementation will almost certainly use native methods, and may just call existing methods in the OS.
If you are specifically looking for line drawing algorithms, another option would be to look at the Wikipedia page for the Bresenham (aliased) or Wu (antialiased) algorithm.
Edit:
The part of a Graphics2D call that actually puts pixels on the screen is probably inside a system call and therefore the source would not be available.
A java vector graphics library like Batik might have source for some of these algorithms, but probably relies on the Graphics2D calls for most of them. So, you might look for a comprehensive vector graphics library written in a language other than Java, where those graphics calls do not already exist by default.
Alternately, checking the table of contents for a computer graphics book might point you at a variety of algorithms that you could look up on Wikipedia.
For any given library:
Make sure to obey all licenses when using another's code
If you are referring to the Java SDK source code, you can find it here: http://grepcode.com/
If the project is open source, you can usually just get the source from the project website. No problem, though make sure to obey their license.
If the project is NOT open source, well, then you're in a pickle licensing wise, so I do NOT endorse this, however, you would need to use a Java Decompiler such as JD-Gui
As far as what drawing algorithms to use, there are so many different ones (obviously, people have been trying to draw quickly for many many years), your best bet is to figure out exactly what you need to do and then search for that specific need separately. There isn't really a good repository of ALL of them, except maybe wikipedia.
If you are using the libraries they are on your classpath. Check out how to figure out your classpath in whichever IDE you are using and you can find the JARs you depend on. If they are packaged with sources all you need to do it unjar them and look at the sources.
If you don't have access to the sources you can get the code using a Java Decompiler.
If you are trying to look at a standard Java library, see the other answers about getting the source to the JDK.
If you are interested in an open source library (such as something maintained by the Apache project), look on the site of the project for a 'source jar' which you can open with a standard zip utility.
If the library you want is not open source or you cannot find the source for it, you can try to decompile it. If you are using Eclipse, try this decompiler.
tldr; at bottom.
Ok, so once again an interesting problem and I'm looking for a fun and interesting solution.
My current project involves being very modular, meaning the program functionality will be easily changed based on different modules and the program would adapt.
So I started out with the typical route, which is using DLL plugins. Now this is just way to normal, I want to think outside the box a bit.
The modules included in my program are long running campaigns that may take weeks to finish, and there will be many running at a time. So stability is a big issue, so I thought about what Google Chrome does. Processes, not DLLs or threads.
So I have a framework going and I need a way to get some information about each module (which are now EXEs). Now for my DLL framework I was exporting a "Register" function that would fill in some information.
So I thought to myself, hey EXEs can export functions, let's see if that actually works...It doesn't. I did some research into how Windows handles theses things and I don't feel like hacking the PE headers on the fly (but it's the out of the box kind of thinking I'm going for).
I'm planning on using named pipes and CLI parameters to transfer data between the main program and the module exe's. I could use that in a register fashion, but I want to here other peoples thoughts.
tldr: I'm using EXE's instead of DLL's for plugins. Looking for a way to easily export one time information like a exported "Register" function would on a DLL. Thoughts?
You might still consider having the modules written as DLLs with defined entrypoints (e.g., the Register function). Then you write the executable that loads the specified DLL. Your main application would fire off the driver executable and give it a name of a plugin DLL.
That way it is still easy to define and export the set of APIs that must be provided yet still run it as a separate process. The one executable that you write can load the specified DLL and then handle the necessary IPC with the main app.
You could define a protocol via the stdin/stdout, named pipes, sockets, etc.
I have successfully used 'plain' COM for several projects, and objects inheriting from TAutoObject. The bonusses here are IDL; the interopability with .Net, VBA and other non-Delphi things; and the fact that implementors still can choose wether to supply a DLL, an exe, an NT-service, and optionally run hosted over the network (COM+/DCOM). There may be several considerations you should handle about multi-threading and locking, but I found all that I needed to know online.
You can, of course, not use symbols exported by a (running) exe since it is running in another boundary. But, you can load an exe as an image (as you would do with a library) using LoadLibrary(Ex) and then, use the functions exported by the exe. I have tested (just for fun) when debugging PeStudio. See the snapshot below of chrome.exe loaded in the process space of PeStudio.exe using LoadLibrary.
I've got simple java-based ppt->swf sub-project that basically works. The open source software out there, OpenOffice.org and JODConverter do the job great.
The thing is, to do this I need to install OO.o and run it in server mode. And to do that I have to install OO.o, which is allot of software (~160MB) just to convert the source PPT files to an intermediate format. Also, the public OO.o distributions are platform specific and I'd really like a single, cross platform set of files. And, I'd like to not interfer with a system's current settings, like file extension associations.
As things are now, my project is not particularly 'software distribution friendly'.
So, the questions are:
Is it possible to create a custom distribution of OpenOffice? How would one about this?
How lightweight and unobtrusive can I make the installation?
Would it be possible to have a truly cross platform distribution since there would be no OO.o UI?
Are there any licensing issues I need to be aware of? (On my list of things to check out, but if you them already then TIA!)
I have no idea to accomplish such task, but Microsoft has its PPT viewer that is for free and very small, maybe in .NET (C#) you can use some kinda function to save into a intermediate file that you need...
and by the way, how are you handling slide transictions?
I found a software that does that but you need MS PPT installed.
this was just an idea, now regarding your actually question:
you can create your own installation of OO, just jump to the Installation project and follow the lines.
I did not read 'til the end, but from the 1st paragraph it seams what you are searching for.
No, not unless you are neck deep coding in the OpenOffice project.