When I run elm repl , I always have to import modules before looking at anything, including Main. I want all of Main's imports also imported into the repl, without typing them out each time. Is that possible?
The closest thing I can think of is like: head -n 5 src/Main.elm | tail -n 4 | elm repl . Which does get evaluated but then elm repl quits after.
Related
I'm trying to write some Idris 2 code reimplementing the examples shown in the Idris2 paper.
When trying to import the L type by setting
import Control.Linear.LIO and loading the file, I get the following error in the Repl:
Error: Module Control.Linear.LIO not found
Any suggestions?
You need to explicitly include contrib as a package. Run Idris like
$ idris2 -p contrib filename.idr
Is there a way to start the Perl 6 REPL with definitions loaded from a file?
I.e. let's say I have this in test.p6:
sub abc() { say 123; }
I'd like to be able to start the perl6 REPL and load that file so that I can use abc interactively.
I guess the easiest way would be to put your code in a .pm6 file, e.g. ./Foo.pm6, mark the subroutines in question with is export and then start Rakudo Perl 6 like this:
$ perl6 -I. -MFoo
To exit type 'exit' or '^D'
> abc
123
This is a bit of a follow-up question to this one.
Say I've managed to extend the Integer class with a new method 'square'. Now I want to use it.
Calling the new method from within the file is easy:
Integer extend [
square [
| r |
r := self * self.
^r
]
]
x := 5 square.
x printNl.
Here, I can just call $ gst myprogram.st in bash and it'll print 25. But what if I want to use the method from inside the GNU smalltalk application? Like this:
$ gst
st> 5 square
25
st>
This may have to do with images, I'm not sure. This tutorial says I can edit the ~/.st/kernel/Builtins.st file to edit what files are loaded into the kernel, but I have no such file.
I would not edit what's loaded into the kernel. To elaborate on my comment, one way of loading previously created files into the environment for GNU Smalltalk, outside of using image files, is to use packages.
A sample package.xml file, which defines the package per the documentation, would look like:
<package>
<name>MyPackage</name>
<!-- Include any prerequisite packages here, if you need them -->
<prereq>PrequisitePackageName</prereq>
<filein>Foo.st</filein>
<filein>Bar.st</filein>
</package>
A sample Makefile for building the package might look like:
# MyPackage makefile
#
PACKAGE_DIR = ~/.st
PACKAGE_SPEC = package.xml
PACKAGE_FILE = $(PACKAGE_DIR)/MyPackage.star
PACKAGE_SRC = \
Foo.st \
Bar.st
$(PACKAGE_FILE): $(PACKAGE_SRC) $(PACKAGE_SPEC)
gst-package -t ~/.st $(PACKAGE_SPEC)
With the above files in your working directory containing Foo.st and Bar.st, you can do a make and it will build the .star package file and put it in ~/.st (where gst will go looking for packages as the first place to look). When you run your environment, you can then use PackageLoader to load it in:
$ gst
GNU Smalltalk ready
st> PackageLoader fileInPackage: 'MyPackage'
Loading package PrerequisitePackage
Loading package MyPackage
PackageLoader
st>
Then you're ready to rock and roll... :)
I like it when terminal/console test runs actually show their output in either red or green text. It seems like a lot of the testing libraries available for Go have this. However, I'd like to just use the default testing package that comes with Go. Is there a way to colorize it's output with red and green?
You can use grc, a generic colourizer, to colourize anything.
On Debian/Ubuntu, install with apt-get install grc. On a Mac with , brew install grc.
Create a config directory in your home directory:
mkdir ~/.grc
Then create your personal grc config in ~/.grc/grc.conf:
# Go
\bgo.* test\b
conf.gotest
Then create a Go test colourization config in ~/.grc/conf.gotest, such as:
regexp==== RUN .*
colour=blue
-
regexp=--- PASS: .*
colour=green
-
regexp=^PASS$
colour=green
-
regexp=^(ok|\?) .*
colour=magenta
-
regexp=--- FAIL: .*
colour=red
-
regexp=[^\s]+\.go(:\d+)?
colour=cyan
Now you can run Go tests with:
grc go test -v ./..
Sample output:
To avoid typing grc all the time, add an alias to your shell (if using Bash, either ~/.bashrc or ~/.bash_profile or both, depending on your OS):
alias go=grc go
Now you get colourization simply by running:
go test -v ./..
You can create a wrapper shell script for this and color it using color escape sequence. Here's a simple example on Linux (I'm not sure how this would look on windows, but I guess there is a way.. :) )
go test -v . | sed ''/PASS/s//$(printf "\033[32mPASS\033[0m")/'' | sed ''/FAIL/s//$(printf "\033[31mFAIL\033[0m")/''
There's also a tool called richgo that does exactly this, in a user-friendly way.
You would still need a library to add color escape code like:
for Windows: mattn/go-colorable or shiena/ansicolor
for Unix or Windows: fatih/color or kortschak/ct
for Unix or Windows: logrusorgru/aurora (mentioned by Ivan Black in the comments)
From there, you specify what you want to color (StdOut or StdErr, like in this example)
rakyll/gotest (screenshot) is a binary that does this.
Example:
$ gotest -v github.com/rakyll/hey
Emoji
You can use colors for text as others mentioned in their answers to have colorful text with a color code or using a third-party library.
But you can use emojis instead! for example, you can use⚠️ for warning messages and 🛑 for error messages.
Or simply use these notebooks as a color:
📕: error message
📙: warning message
📗: ok status message
📘: action message
📓: canceled status message
📔: Or anything you like and want to recognize immediately by color
🎁 Bonus:
This method also helps you to quickly scan and find logs directly in the source code.
But some distributions of Linux default emoji font are not colorful by default and you may want to make them colorful, first.
BoltDB has some test methods that look like this:
func assert(tb testing.TB, condition bool, msg string, v ...interface{}) {
if !condition {
_, file, line, _ := runtime.Caller(1)
fmt.Printf("\033[31m%s:%d: "+msg+"\033[39m\n\n", append([]interface{}{filepath.Base(file), line}, v...)...)
tb.FailNow()
}
}
Here are the rest. I added the green dots here.
I have to do the verification of DPRAM.
Each test case is written in different file named test1.v,test2.v etc.
I want to write a script(unix) such that when I type run test1.v then only that test case will run.
Note :- test1.v contents only task which includes read assert,write assert etc.
The test bench is a separate file which includes clock and component instantiation.
when run test1.v is done then it should link the test1.v task to the testbench and then output is obtained.
I have done the coding in verilog
How to do this?
So, as far as I can make out, your different tests, or 'testcases' are in files named test<n>.v. And I'll assume that each of these testcases has a task that has the same name in all files, say run_testcase. This means that your testbench (testbench.v, say) must look something like:
module testbench();
...
`include "test.v" // <- problem is this line
...
initial begin
// Some setup
run_testcase();
//
$finish;
end
endmodule
So your problem is the include line - a different file needs to be included depending on the testcase. I can think of two ways of solving this first one is as toolic suggested - using a symbolic link to 'rename' the testcase file. So an example wrapper script (run_sim1) to launch your sim might look a bit like:
#! /usr/bin/env sh
testcase=$1
ln -sf ${testcase} test.v
my_simulator testbench.v
Another way is to use a macro, and define this in the wrapper script for your simulation. Your testbench would be modified to look like:
...
`include `TESTCASE
...
And the wrapper script (run_sim2):
#! /usr/bin/env sh
testcase=$1
my_simulator testbench.v +define+TESTCASE=\"${testcase}\"
The quotes are important here, as the verilog include directive expects them. Unfortunately, we can't leave the quotes in the testbench because it will then look like a string to verilog, and the TESTCASE macro won't be expanded.
One way to do it is to have the testbench file include a test file with a generic name:
`include "test.v"
Then, have your script create a symbolic link to the test you want to run. For example, in a shell script or Makefile, to run test1.v:
ln -sf test1.v test.v
run_sim
To run test2.v, your script would substitute test2 for test1, etc.