I am using jupyterlite which is JupyterLab distribution that runs entirely in the browser.
However, after clearing the browser history, the files are no more visible.
Please let me know how can I retrieve the *ipynb files from my windows machine.
I have already checked %AppData% and I don't see any *ipynb files.
The files are stored in well... the browser. Specifically in the IndexDB or localStorage. This means that the physical location on the disk will depend entirely on the browser that you use, rather than on the operating system, and will likely be inaccessible (for an average user) without decoding binary blobs.
For example, in Chrome you can check the path to the application data using chrome://version/ (under Profile Path) and in that directory there should be IndexedDB folder. Then you need to find a sub-folder depending on the domain in which you accessed JupyterLite, for example https_jupyterlite.readthedocs.io_0.indexeddb.leveldb, and there you will find a LevelDB database file with .ldb extension and a MANIFEST file (with the pointer to the current version in the CURRENT file. The details of how to extract the blobs are outside of scope for this answer, but have a look at How to access Google Chrome's IndexedDB/LevelDB files?.
However, you can use files from your file system directly in JupyterLite without worrying about in-browser technologies with the jupyterlab-filesystem-access extension which uses File System Access API however this API is not available on Firefox yet.
As noted by #Wayne all of this is still quite experimental (both as in "using the newest browser APIs" and "the team of developers is still figuring way forward, please help by providing kind feedback and contributing").
Related
I'm new to openui5 and i'm trying to understand how the openui5 cache buster works by reading through the documentation. I don't understand where I can find the generated sap-ui-cachebuster-info.json, am I supposed to be able to find it in my server (after build)?? or can I access it and read its content in some way? Am I supposed to see it in the list of files my browser receives in the network tab? Can I read it at all?
'sap-ui-cachebuster-info.json' file is generated on the server and usually located in the server root directory.
it's contains information about the version of the OpenUI5 library in use and the corresponding file names,
file content is not accessible to the client, it is read by the server when serving the library files. You can inspect it using browser development tools
Here's what I know:
When uploading files given by users, we should put them in a folder
outside the deployment folder. Let me call it D:\uploads.
We should (somehow) add that folder (D:\uploads) as a web app context.
Here's what I did:
I upload my files to the folder D:\uploads.
I tried adding the web app context as it's mentionned here by adding the following row to TOMCAT_DIR/conf/server.xml:
<Context docBase="D:\uploads" path="/uploads"/>
But that doesn't have any effect. When consulting http://localhost:8080/uploads/file.png or http://localhost:8080/uploads I get a HTTP Status 404 error.
So what I want to know:
What did I do wrong ? How can I add my upload folder to Tomcat?
Is there any better approach when it comes to uploading files ?
Because I'm wondering what should I change if I want to deploy my
application to another server where there's no D:\uploads.
Change the docBase attribute. Use D:/uploads (with slash) instead of D:\uploads (with backslash).
When dealing with files in Java, you can safely use / (slash, not backslash) on all platforms.
Regarding the differences you mentioned in the comments when starting the Tomcat from the IDE and from bin/startup.bat: It's very likely when you start the Tomcat from the IDE, it is not using the same context.xml your Tomcat is using. Just review the Tomcat settings in the IDE.
How to store uploaded files is a common topic at Stack Overflow. Just look around and you'll get surprised in how this topic is popular.
If you aren't happy enough in storing your files in D:/uploads or you'll have other servers accessing the files, you could consider storing them in some location in your network. Depending on your requirements, you can have one dedicated server to store your files or just share the folder which contains the files in your current server. The right decision will always depend on your requirements.
I am writing a number of Google Packaged Apps which run independently, but share lots of code. For example, they all use "library.js". I would like to have only one copy of library.js so any changes to it will be used by all newly packed apps.
To package my apps, it seems they all must have a copy of library.js in their own directory structure, whereas it would be nice to have a single master copy in some other directory that is accessible to all. I currently do a manual check to make sure all files are up-to-date before packing, and I am writing some code to do the check automatically, but it seems like a work-around.
Can a Google Packaged App use JS code in external library directories, or must all code be under the root directory of the app (i.e., requiring copying from external directory) when packing?
Have you tried providing a URL i.e. host the javscript file in .js format to an accessible location to your apps and then provide the .js file URL in all your apps code. The very next time you want to change, all you have to do is to update that .js file.
Is it common for a developer to keep their NAnt global configuration file (NAnt.exe.config) in version control?
And should or shouldn't the the rest of the files in the NAnt installation be added to the ignore file of the version control system?
One use of version control is as a backup. If the only copy of NAnt.exe.config is on a hard disk that dies, it will take some effort to reconstruct it (along with everything else that disappeared and wasn't backed up).
From the corporate perspective, having all of the work in progress backed up is a method for preserving assets. The corporate owner of the source code asset is assured that the asset will not be destroyed.
When there is another backup strategy, then sometimes the rule of thumb is not to put anything into version control that should not be shared with other developers. Such as customized data relevant only to one user and/or machine, or confidential information.
I keep a copy of the NAnt code for the version I'm using. This includes the .config file. This is so my build system is safe from "it disappeared from the internet" events (unlikely, but still).
Beyond that I see no reason to keep it around on your code repository, unless for some reason you've modified it somehow. Most everything in NAnt can be overridden in build files, like the target framework and so on.
Is it possible to keep the attributes of a version controlled file unchanged? I have a directory structure which I'd like my installer to recreate on the client machine. I was hoping the entire directory could be placed on VCS without affecting the file attributes.
I'm using TFS but would also like to hear about other version control systems.
Edit: I'm talking about Windows file system attributes such as Hidden/Archive/System/Read-only but any other information such as creation/modification dates is also welcome. I have a directory structure in which some files are read-only and need to have those files installed as such on the client's machine. TFS tends to set/unset the read-only attribute depending on whether the file is checked-in or checked-out.
TFS does not store the file attribute data (such as created date, modified date) etc in the current versions of TFS. The values for those attributes will be the time on the local computer when the files is first downloaded / modifed.
TFS 2010 has the ability to attach arbitrary metadata to version control objects. You'd have to write your own tool, however.
API specification (prelease): http://blogs.msdn.com/mrod/archive/2008/05/09/team-foundation-server-properties.aspx
Usually version control systems do not store full metadata information about the files under its control in repository. In usual usage of version control systems this is not needed, and might have even cause problems; version control systems store "sane" subset of metadata (like e.g. executable permissions, and symbolic links).
Possible solution is to use hooks to save required parts of file metadata on commit to some file (usually plain text file), keep this file under version control to distribute it automatically to all clients, and use hooks to restore metadata on checkout.
Example solutions of tools to save and restore metadata include (unfortunately examples are for Git, and not TFS, but it is the idea that matters):
metastore
git-cache-meta
Example solutions of tools to keep configuration files under version control (again: all of them using Git as a backend) include:
IsiSetup
etckeeper
giterback