I started using NixOS a few days ago. It seems like there is a configuration option for everything, e.g. hardware.opengl.driSupport32Bit or system.copySystemConfiguration.
But the question is: can I see all options which are available? To give a few examples:
How should I know what desktopManagers are available other than the "kde4", "kde5" and "gnome3"?
What synaptics options can I use, other than accelFactor and twoFingerScroll?
You can search them at http://nixos.org/nixos/options.html or get the whole list at http://nixos.org/nixos/manual/options.html.
It's also possible to get the list at man configuration.nix
there is also:
nix-repl
nixos-option
both are very powerfull tools to query the system's configuration.
finally, if you want to use nixos options offline, you should have a look at this:
https://lastlog.de/blog/posts/nix-assistant.html
Related
I may have missed this, but where in the documentation (in the latest spark version, 3.1.2 at the moment of posting) can we find the options that we can pass to the option method:
df.write.format('parquet').option(???).mode(saveMode='overwrite').saveAsTable('tmp')
For example, I have seen that maxRecordsPerFile is probably a valid option (https://mungingdata.com/apache-spark/partitionby/). Where can we find the whole list of options and their meaning? Do we still need to go through the source (Where is the reference for options for writing or reading per format?)?
Also, is it better to pass options through .option() or within .saveAsTable()?
I'm trying to vusb-analyzer.
It requires *.mon log file.
How can I make usbmon log file (*.mon)?
https://www.kernel.org/doc/Documentation/usb/usbmon.txt
The document you linked in your question is actually the answer, please see the sections 1-3.
In section 3, it says:
# cat /sys/kernel/debug/usb/usbmon/0u > /tmp/1.mon.out
This will create a text file 1.mon.out. Its structure is also described in the same document.
Now, how do I know that this is the file to be opened by vusb-analyzer? From what I see, the website of this project doesn't make it clear what the *.mon file is.
However, you can see it in the source code:
https://github.com/scanlime/vusb-analyzer/blob/master/VUsbTools/Log.py#L498
It clearly states, that the program uses the syntax described in the document that you already know:
https://www.kernel.org/doc/Documentation/usb/usbmon.txt
The name of your file doesn't really matter, but if you want it to end with ".mon", you could simply use:
# cat /sys/kernel/debug/usb/usbmon/0u > ~/somefile.mon
Two warnings:
The line with cat I posted here is just an example and in order to use it, you will need to follow the steps in the document (it won't work without enabling usbmon first)
vusb-analyzer hasn't been updated for years and I wasn't able to run it on my machine. Its website mentions Ubuntu 8.10 so I wouldn't be surprised if others had problems running it, too. (For example, in order to reproduce your problem, provide more help).
Sorry if the title is a bit confusing, but what are the options/conventions that Origen provides for setting up subblocks that aren't necessarily silicon models, or are just general helpers?
For example, I have a scan helper plugin that guides the user through creating a scan test program. I'd like to add a list of options/customizations to the top-level app. There are a few ways to do this:
I can add a list of attr_readers/methods. I think this looks a bit ugly though and adds a bunch of stuff to the toplevel that isn't used by anything else, and it blows up $dut.methods.
I could use parameters as defined here: http://origen-sdk.org/origen/guides/models/parameters/ and just call of them in the scan tester app. But looking at the guides I don't think that is the desired use case. It looks more like context switching, but maybe that was just the example use case.
I could add a scan_tester.setup method or something on the toplevel. This just seems unnecessary though since its basically doing the same thing as #2, but requires a 'setup' method to be called. Yeah, its only 1 line, but if you mess up or forget to add that line then you've got some debug to do avoided by #2 (I can print a warning for example if the scan parameters aren't provided to help warn of typos, etc.).
I can set it up as a subblock (currently how I've got it), but this doesn't really fit. Scan isn't a silicon model, so base address is useless, but required. It has no registers, etc.
Then there's other 'Ruby' things I could do (setup via on_create, use global variable etc.) but these all seem not as great as any of the options above for one reason or another (mainly, more setup required on my part than using any of the existing options).
Any one of these would work. But from a convention standpoint, which direction should my scan tester setup go? Is there another option I hadn't considered? I'd lean towards option #2 as it looks the cleanest.
Thanks
This is a really good question.
There are actually two other options:
Add application config parameters from the plugin: http://origen-sdk.org/origen/release_notes/#v0_7_24
Define a constant as used by the JTAG and other early plugins: http://origen-sdk.org/jtag/#How_To_Use
I think #2 is using parameters in a way that was not originally intended, maybe it could work though but I just can't picture it.
I don't really like #5 or #6 since they provide application-level and class-level configuration, which is sometimes what you want, but often these days I see the need more for (DUT) instance-level configuration.
So, my best answer here is that I don't know, but you are touching on a good point that we need to have an official API or at least a recommendation for this.
I think you should be open to the possibility of adding something new to Origen for this if you can think of something better.
As I'm writing this, I suppose #5 would also support instance-level configuration, albeit a bit long-winded:
def initialize(options = {})
Origen.app.config.scan_chain_length = 6
end
My comment wouldn't keep its format, so here it is but looks better:
#Ginty
What would you think of a 'component' API. For example, we could have:
# components.rb
component(:scan, TIPScan::ScanTester,
# options
wgl_dir: ..., # defaults to Origen.app.root/pattern/wgl
custom_sort: proc do {|wgl_name| ...},
)
# then we can do things like:
$dut.scan #=> TIPScan instance
$dut.component(:scan) #=> same as above
$dut.components #=> [TIPScan instance, ...]
$dut.has_component(:scan) #=> true etc.
Pretty much just a stripped down subblock class to handle these. I think our IAR/C compilers and even CATI could benefit from this and make the setup cleaner and more customizable.
I am required to make a custom FireFox profile on a RHEL based system.
most of the configuration are changed inside the FireFox inside the about:config menu.
When I try and lock parameter values using the "mozilla.cfg" file and the "lockPref("", )" function the browser doesn't seem to read those files, I place the file both in: "~/.mozilla/firefox/" and "/usr/lib64/firefox/". I used the http://kb.mozillazine.org/Lock_Prefs guide and some more and still I have no one answer about where those function should be written and how do I check that those functions were loaded.
I would like some clear instructions or a definitive guide that I just couldn't manage to find.
Thanks!
This came up fairly high in a Google search when I was asking the same question, but did not have an answer at the time.
I found the following reference:
https://developer.mozilla.org/en-US/Firefox/Enterprise_deployment
On RHEL7, the files needed to be added to the following locations:
/usr/lib64/firefox/defaults/preferences/autoconfig.js (root:root, 644)
/usr/lib64/firefox/mozilla.cfg (root:root, 644)
I came across echofunc.vim today (from a link in SO). Since I'm rubbish at remembering the order of function parameters, it looked like a very useful tool for me.
But the documentation is a bit lean on installation! And I've not been able to find any supplementary resources on the internet.
I'm trying to get it running on a RHEL box. I've copied the script into ~/.vim/plugin/echofunc.vim however no prompt when I type in a function name followed by '('. I've tried adding
let g:EchoFuncLangsUsed = ["php","java","cpp"]
to my .vimrc - still no prompting.
I'm guessing it needs to read from a dictionary somewhere - although there is a file in /usr/share/vim/vim70/ftplugin/php.vim, this is the RH default and does not include an explicit function list.
I'm not too bothered about getting hints on the functions/methods I've defined - just trying to get hints for the built-in functions. I can see there is a dictionary file available here which appears to provide the resources required for echofunc.vim, I can't see how I set this up.
TIA,
It expects a tags file, the last line of the description describes exactly how to generate it:
ctags -R --fields=+lS .
It works here with PHP but not with JS. Your mileage may vary.
I didn't know about this plugin, thanks for the info.
You should try phpcomplete.vim, it shows a prototype of the current function in a scratchpad. It is PHP only, though.