Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 1 year ago.
Improve this question
I want to start learning Forth (like in the related Stack Overflow question Is it practical to learn and use Forth?). I see that there are many implementations. I would like to use a
ANS 1994 compatible version (if reasonable, but sticking to the standard might be good)
small and compact implementation, I don't want a full OS.
Windows
easy to use, I am new to Forth ;-)
What particular implementation can be recommended?
Win32Forth is really fantastic, as mentioned above. It has a nice integrated development environment and is a pretty modern implementation that seems to match up very well with the standards as well as including some more experimental but widely-accepted features.
I use Gforth, but I also use Vim to edit source files. :) Gforth is good and "classic" as far as the features it supports. It gives you a very "old school" Forth experience without being overly quirky to use. (Some free Forths do odd things with their command lines and such - I use Brodie's "Starting Forth" as the model of how a Forth interpreter should behave.)
I looked at SwiftForth, which is a very nice "high tech" Forth system that goes well beyond what the classic Forths offer in terms of language features and really brings Forth into the modern programming world. If you want to actually do Forth programs professionally, SwiftForth looks like it can handle just about anything you want to do with it.
Some time ago I evaluated 4tH, an implementation of Forth.
I think it meets all of
your requirements. For instance the compiler is only 61 KB. There is also full support for floating point numbers, important if you want to
try to use it for technical/scientific purposes.
4tH runs on most operating systems, including MS-DOS, MS-Windows (both 16 bit and 32 bit), Linux, Coherent, AIX, SunOS, BOS, BSD, Mac OS X, BeOS, RISC OS, etc. Download (Windows installer, 1.5 MB, includes the manual). Manual (PDF, 1.1 MB).
There is an active community centered around the Google Group 4tH-compiler.
For instance today I received two messages.
Please note that in 4tH you can't define your own defining words (words executing at compile time). This is not a serious
limitation, unless you want to cover advanced Forth features.
To get you started (as this is not very clear from the manual or the interactive compile), after installation copy the compiler, 4th.exe, to an empty folder, make two files in this directory, HelloWorld.bat and HelloWorld.4th, and run HelloWorld.bat:
HelloWorld.bat:
4th.exe cx HelloWorld.4th
pause
HelloWorld.4th:
: hello ." Hello from XYZ!" cr cr ;
hello
SwiftForth. It isn't self-consciously small and compact; it just happens to be. It's easy to use (LOCATE WH EDIT , a nicer than usual WORDS), comes with two books, and has an excellent mailing list with over a decade of archives. The evaluation version won't let you compile turnkey apps or DLLs; it still provides an excellent console for a student, and can support scripts in the usual ways. Quick Windows examples:
: sleep-monitor ( -- )
HWND_BROADCAST WM_SYSCOMMAND SC_MONITORPOWER 2 SendMessage drop ;
library dnsapi.dll
( ... DLL imports, constants ... )
variable results
: DnsQuery ( z -- res )
DNS_TYPE_A 0 NULL results NULL DnsQuery_UTF8 ;
: resolves? ( z -- f )
DnsQuery if false exit then
results # DnsRecordListFree true ;
\ an example use of the dialog compiler
\ this compiled DSL is an example of something that 4th
\ precludes with its "not ... serious limitation"
DIALOG (HELLO-ABOUT)
[MODELESS " About Hello" 10 10 120 70
(FONT 8, MS Sans Serif) ]
\ [class text id x y sx xy ]
[CTEXT " HELLO" -1 10 10 100 10 ]
[CTEXT " (C) 1997 Forth, Inc." -1 10 25 100 10 ]
[CTEXT " http://www.forth.com" -1 10 35 100 10 ]
[DEFPUSHBUTTON " OK" IDOK 35 50 50 14 ]
END-DIALOG
Download Gforth for PC and Android.
Tinker with it using it as a calculator, solving simple problems, Fibonacci, solving the quadratic a b c, etc.
I realise they might not meet all your requirements but the following Forth-like languages might also interest you from a learning perspective.
Factor
RetroForth
Additionally, I have found the Re-Factor blog to be a good introduction to Factor.
If you can find a copy of FORTH Inc's old polyFORTH, and an old x86 that can run it, this is the language used in Leo Brodie's original "Starting FORTH". It is a clean and very robust FORTH.
I recommend ciforth, as you're a Windows user the version built for Windows is known as wina: an MS-WIndows NAtive Forth.
ciforth is a small system written in NASM assembler, and comes with a similar interface for a wide variety of systems. It's small, fast, classic (blocks ftw), easy to use as it's old school, comes with a ton of documentation and a wordlist that isn't overwhelming like Gforth's (the wordlist for Lina is here, the only difference between lina and wina are in words that access the underlying OS: linux/MS-Windows).
Gforth has a lot of bloated definitions and some of Starting Forth won't work in it, for example.
The only thing the official release of ciforth lacks is a floating point stack, but Forth can deal with fixed point incredibly well (if one reads Starting Forth, one learns about how to use it).
wina versions can call dll functions just fine, in 32 and 64 bit, but can also make turnkey applications that call dll functions.
Beta releases have floating point as a loadable extension.
Win32Forth worked well for me.
durexForth is an ANS compliant C64 Forth and very small.
Related
I am using a Keygen application (.exe). There are two input fields in it's GUI:
p1 - at least 1 digit, 10 digits max - ^[0-9]{1,10}$
p2 - 12 chars max - uppercase letters/digits/underscores - ^[A-Z0-9_]{0,12}$
Pressing generate button produce a key x.
x - 20 digits exactly - ^[0-9]{20}$
For each pair (p1,p2), there is only one x (in other words: f(p1,p2) = x is a function)
I am interested in it's encryption algorithm.
Is there any way of reverse engineering the algorithm?
I thought of two ways:
decompiling. I used snowman, but the output is too polluted. The decompiled code probably contains non-relevant parts, such as the GUI.
analyzing of input and output. I wonder if there any option to determine the used encryption algorithm by analyzing a set of f(p1,p2) = x results.
As you mentioned, using snowman or some other decompiling tools is probably the way to go.
I doubt you would be able to determine the algorithm just by looking at the input output combinations, since it is possible to write any kind of arbitrary algorithm, that can behave in any way.
Perhaps you could just ask the author what algorithm they're using ?
Unless it's something really simple, I'd rule out your option 2 of trying to figure it out by looking at input and output pairs.
For decompiling / reverse engineering a static binary, you should first determine whether it's a .NET application or something else. If it's written in .NET you can try this for decompilation:
https://www.jetbrains.com/decompiler/
It's really easy to use, unless the binary has been obfuscated.
If the application is not a .NET application, you can try Ghidra and/or Cutter which both has pretty impressive decompilers built in:
https://ghidra-sre.org/
https://cutter.re/
If static code analysis is not enough, you can add a debugger to it. Ghidra and x64dbg work really well together, and can be synced via a plugin installed in both.
If you're new to this, I can recommend both that you look into basic assembler for the x86 platform so you have a general idea of how the CPU works. Another way to get started is "crackme" style challenges from CTF competitions. Often there great write-ups with the solution, so you have both the question and answer available.
Good luck!
Type in p1 and p2. Scan the process for that byte string. Then put a hardware breakpoint for memory access on it. Generate the key, it will hit that hardware breakpoint. Then you have the address which accesses it and start reversing from there in Ghidra(Don't forget to use BASE + OFFSET) since ghidra's output won't have the same base as the running application. The relevant code HAS to access the inputs. So you know where the algorithm is. Since it either directly accesses it, or somewhere within that call chain is accessed relatively fast. Nobody can know without actually seeing the executable.
I have a very simple monocolor icon for AR that needs to emit light. How can I edit the MTL file to make it do so?
This is what I made so far but is not glowing.
newmtl #63c7b2
Kd 0.3058824 0.8470588 0.5921569
Ka 0.3882 0.780 0.6980
Ke 17 12 4
illum 2
Even though this post is over 2 years old, it's sad it only received one wrong answer, adding this question to the billions of unanswered (or incorrectly answered) questions littering the internet. So, here's the answer to it finally to get one more unanswered question off the internet.
Emission is handled by rendering of whatever software you use to render the OBJ, just like how the software is responsible for applying the normal map.
To respond to that bluntly wrong answer above that said "MTL files offer no form of emission support and Ke is not a valid keyword", I will paraphrase Luke Skywalker: "Everything part of what you just said is wrong."
-There is an "map_Ke" keyword, although un-official like most of MTL's keywords, and MTL's do offer emission support, the software that processes the MTL file (and OBJ) just has to support it also.
example:
map_Ke texture.png
or even
map_Ke -s 1 1 1 -o 0 0 0 -mm 0 1 texture.png
So basically, you can have emissions in OBJ's but the 3D software you use that loads the OBJ and MTL has to know how to apply emissions. Most 3D software can apply emissions but not many expect emission data from an OBJ file so they don't look for or process it. So solution to this question is "use 3D software that can fully process an OBJ file with emissions". Admittedly that will be hard to find.
There's probably a few out there, the old "Honorsoft OBJ Importer" does, but it's been made private.
-Maybe try Blender? Here's proof (from other people) of what I said already though:
-To any still saying that emissions in OBJ aren't officially supported, that's not true. Emissions are supported and have been given a specific Ke. What people have to understand is it's not the format that is not supporting emissions, it's the 3D software you're using to process the OBJ that doesn't support emissions, or at least doesn't bother to process them from OBJ's. I have used and made OBJ software that supports emissions and can even process rig data, just like in DAE.
-Like I said, most statements in OBJ are unofficial, but that's just because the developers of Wavefront don't care much about it anymore and don't bother to update the "official" docs.
...and software that doesn't support a simple emission line is like making a video-player that doesn't support audio.
MTL files offer no official form of emission support and thus Ke is not a valid keyword, although some applications will unofficially understand it, and proposals for its extension have been made.
If you have the freedom to do so, switching to a software that understands it, or, preferably, another format that supports emission, might fix this issue for you. If not, the best you can do is use illum 0 to make it so that the material isn't affected by lighting.
Source1 / Source2
I was looking in and saw this comment in the indir implementation:
sub indir(Str() $path, $what, :$test = <r w>) {
my $newCWD := $*CWD.chdir($path,:$test);
$newCWD // $newCWD.throw;
{
my $*CWD = $newCWD; # temp doesn't work in core settings :-(
$what();
}
}
I thought this use of my was strange, which led to doc issue #1082 niggling about if my is actually lexical. I would have thought that temp would be more appropriate for user-level temporary changes to dynamic variables.
But now, I see this comment, but I'm not quite sure what it means. Is temp broken this deep? Is it not available here? Or is the comment just wrong?
If the comment is right, has this way of dealing with dynamic variables leaked up to the everyday programmer level because that is what some people have to do in the guts (and they got used to that?)
And, how low-level is this level really? It seems like all of Perl 6 should be available here.
Perhaps the comment in the source code would be less misleading if it was:
# temp $*CWD doesn't work in core settings (which we're in)
# my $*CWD = ... is a decent workaround in this case :)
It seems like all of Perl 6 should be available here.
Full Perl 6 must wait until after completion of compilation of the Perl 6 CORE setting. This corresponds to the Rakudo Perl 6 compiler's "core" src tree. This includes the code with the "# temp doesn't work in core settings :-(" comment.
To emphasize #raiph's point: in general, it's unreasonable to expect any particular Perl 6 feature implemented in rakudo to work at any given point in the CORE, because that's how we make the features available.
Developers working on the core have to be aware of this, and take it into account, for example, in ordering how the CORE is built, and which features are available at which point (and further, which features are more performant at a lower level, so the Perl 6 you see in CORE may not be idiomatic for several different reasons.)
Recently (about a month ago) I was trying to introduce new constructs to my company's in-house extension language, and struggling with a couple of reduce-reduce errors. While I eventually solved this problem, digging into the y.output file was no picnic.
As an experiment, I tried using Bison's --graph=<file> option to output a DOT file (note that our standard build uses Byacc, not Bison). As I'm on a 'turnkey' Linux box, I didn't have a Graphviz installation and could not easily install from RPMs (working on Red Hat Enterprise Linux 4). Instead, I built it from source.
As an initial experiment, I tried to run dotty with an output of Postscript. Now our internal language is your average home-grown, Turing-complete, dynamically typed scripting language, but I was unprepared for what followed. The dotty run took over four hours (2GHz dual core AMD64 box)! And when it was done, the graph that was rendered was not what I would call readable.
So, quite simply, I'm looking for advice. Are there a set of switches which would improve the outcome over the 'default' approach I took? I'm looking for experience in
optimizing 'render' time
improving readability of the graph
possible advice on better graphical viewers
I imagine you've already seen this link, but just for completeness, there is a list of viewers etc. at: http://graphviz.org/resources/ or see https://web.archive.org/web/20131005020548/http://graphviz.org/Resources.php for an archived copy.
I've been experimenting with creating an interpreter for Brainfuck, and while quite simple to make and get up and running, part of me wants to be able to run tests against it. I can't seem to fathom how many tests one might have to write to test all the possible instruction combinations to ensure that the implementation is proper.
Obviously, with Brainfuck, the instruction set is small, but I can't help but think that as more instructions are added, your test code would grow exponentially. More so than your typical tests at any rate.
Now, I'm about as newbie as you can get in terms of writing compilers and interpreters, so my assumptions could very well be way off base.
Basically, where do you even begin with testing on something like this?
Testing a compiler is a little different from testing some other kinds of apps, because it's OK for the compiler to produce different assembly-code versions of a program as long as they all do the right thing. However, if you're just testing an interpreter, it's pretty much the same as any other text-based application. Here is a Unix-centric view:
You will want to build up a regression test suite. Each test should have
Source code you will interpret, say test001.bf
Standard input to the program you will interpret, say test001.0
What you expect the interpreter to produce on standard output, say test001.1
What you expect the interpreter to produce on standard error, say test001.2 (you care about standard error because you want to test your interpreter's error messages)
You will need a "run test" script that does something like the following
function fail {
echo "Unexpected differences on $1:"
diff $2 $3
exit 1
}
for testname
do
tmp1=$(tempfile)
tmp2=$(tempfile)
brainfuck $testname.bf < $testname.0 > $tmp1 2> $tmp2
[ cmp -s $testname.1 $tmp1 ] || fail "stdout" $testname.1 $tmp1
[ cmp -s $testname.2 $tmp2 ] || fail "stderr" $testname.2 $tmp2
done
You will find it helpful to have a "create test" script that does something like
brainfuck $testname.bf < $testname.0 > $testname.1 2> $testname.2
You run this only when you're totally confident that the interpreter works for that case.
You keep your test suite under source control.
It's convenient to embellish your test script so you can leave out files that are expected to be empty.
Any time anything changes, you re-run all the tests. You probably also re-run them all nightly via a cron job.
Finally, you want to add enough tests to get good test coverage of your compiler's source code. The quality of coverage tools varies widely, but GNU Gcov is an adequate coverage tool.
Good luck with your interpreter! If you want to see a lovingly crafted but not very well documented testing infrastructure, go look at the test2 directory for the Quick C-- compiler.
I don't think there's anything 'special' about testing a compiler; in a sense it's almost easier than testing some programs, since a compiler has such a basic high-level summary - you hand in source, it gives you back (possibly) compiled code and (possibly) a set of diagnostic messages.
Like any complex software entity, there will be many code paths, but since it's all very data-oriented (text in, text and bytes out) it's straightforward to author tests.
I’ve written an article on compiler testing, the original conclusion of which (slightly toned down for publication) was: It’s morally wrong to reinvent the wheel. Unless you already know all about the preexisting solutions and have a very good reason for ignoring them, you should start by looking at the tools that already exist. The easiest place to start is Gnu C Torture, but bear in mind that it’s based on Deja Gnu, which has, shall we say, issues. (It took me six attempts even to get the maintainer to allow a critical bug report about the Hello World example onto the mailing list.)
I’ll immodestly suggest that you look at the following as a starting place for tools to investigate:
Software: Practice and Experience April 2007. (Payware, not available to the general public---free preprint at http://pobox.com/~flash/Practical_Testing_of_C99.pdf.
http://en.wikipedia.org/wiki/Compiler_correctness#Testing (Largely written by me.)
Compiler testing bibliography (Please let me know of any updates I’ve missed.)
In the case of brainfuck, I think testing it should be done with brainfuck scripts. I would test the following, though:
1: Are all the cells initialized to 0
2: What happens when you decrement the data pointer when it's currently pointing to the first cell? Does it wrap? Does it point to invalid memory?
3: What happens when you increment the data pointer when it's pointing at the last cell? Does it wrap? Does it point to invalid memory
4: Does output function correctly
5: Does input function correctly
6: Does the [ ] stuff work correctly
7: What happens when you increment a byte more than 255 times, does it wrap to 0 properly, or is it incorrectly treated as an integer or other value.
More tests are possible too, but this is probably where i'd start. I wrote a BF compiler a few years ago, and that had a few extra tests. Particularly I tested the [ ] stuff heavily, by having a lot of code inside the block, since an early version of my code generator had issues there (on x86 using a jxx I had issues when the block produced more than 128 bytes or so of code, resulting in invalid x86 asm).
You can test with some already written apps.
The secret is to:
Separate the concerns
Observe the law of Demeter
Inject your dependencies
Well, software that is hard to test is a sign that the developer wrote it like it's 1985. Sorry to say that, but utilizing the three principles I presented here, even line numbered BASIC would be unit testable (it IS possible to inject dependencies into BASIC, because you can do "goto variable".