I'm trying to add additional functionality to the already defined method "compile" in smalltalk.
here is the code I wrote:
compile: code notifying: requestor trailer: bytes ifFail: failBlock
self log:(self substring: code delimiter: $?).
super compile: code notifying: requestor trailer: bytes ifFail: failBlock.
as you can see compile has 4 parameters, I only know what to give the first parameter when calling the method compile (which is the code as a string).
whatever functionality I added isn't relevant, I'm not able to run any tests for my method because I dont know what to give the last 3 parameters.
So my question here is how can i call my method with the right set of parameters.
This is where I got stuck while writing a test for it:
co := ContractObject new.
code := 'rate: aRate
"?This is the Compiler Comment. Log me?"
hourlyRate := aRate. '.
co compile: code. "3 parameters missing here"
Since you mentioned this is a homework assignment, I will not deprive you of discovering the joys of a live, dynamic system like Smalltalk ;) The best tutor is your image itself. For many messages (including the one in question), there are helpful examples right under your finger tips that can give you clues about how to send them.
To find these real world examples, you "Browse Senders" of the message in question and see how these clients handle the parameters you're confused about. In Squeak (you didn't say which dialect and Pharo doesn't have that message), I see two senders in particular that show how to handle those parameters.
If you don't know how to "browse senders", there are many great references to teach you. For me, "Pharo By Example" is my go-to reference for basic "how do I" questions like yours (or "Squeak By Example" if you're using Squeak). This "fishing pole", if you will, will provide you with faster answers, and more understanding, then begging for fish on SO ;)
n.b. When asking Smalltalk questions, please tag the dialect (e.g. Pharo, Squeak, Amber) because not all dialects have the same set of messages (e.g. Pharo does not have the message you asked about)
Related
I have been searching the official docs and existing questions and could not find any information on this - in Elm, how it would be possible to see the members/methods/variables that belong to or are exposed by a package in Elm, (such as the dir method in python), without having to dive into the source code each time?
What I want to do is get a simple list of what methods are exposed by an imported package. (So for a package like List, it should output reverse , all, any, map, etc.) I have attempted tab completion in elm repl and the elm extension available in VS code editor, and elm repl does not offer any methods such as help, doc, ?, dir, man, etc., so I have no idea where to even start. I'm wondering how everyone else does this other than pulling up the source code for each and every package they use.
I apologize for the newbie question and if I misread or have been missing anything, but I couldn't even find anything in the https://elmprogramming.com tutorial. Thanks in advance.
Nothing like this exists in Elm to do reflection over modules, unfortunately (as of 0.19.1, at least).
However, if you aren't looking to actually do this kind of thing at runtime, but rather as a convenient way of finding out for development, the elm packaging system enforces the requirement that all public functions are documented, so if you visit the package page, every public function and type will be documented there (obviously it can't enforce the content of the documentation, but at the very least it will be listed).
With a snippet like
perl6 -e 'loop { FIRST say "foo"; last }'
I get
WARNINGS for -e:
Useless use of LOOP_BLOCK_1 symbol in sink context (line 1)
foo
I know how to work around the warning. I'm wondering about what the source of the warning is. I found this open ticket, but it doesn't seem to have received any attention.
What is this warning about?
And what about this is useless?
Version
$ perl6 --version
This is Rakudo version 2018.06 built on MoarVM version 2018.06
implementing Perl 6.c.
It's a bug, a bogus warning.
I know how to work around the warning.
That's the main thing.
I'm wondering about what the source of the warning is.
It's a bogus warning from the compiler.
I found this open ticket, but it doesn't seem to have received any attention.
I think it got some attention.
bbkr, who filed the bug, linked to another bug in which they showed their workaround. (It's not adding do but rather removing the FIRST phaser and putting the associated statement outside of the loop just before it.)
If you follow the other links in bbkr's original bug you'll arrive at another bug explaining that the general "unwanted" mechanism needs to be cleaned up. I imagine available round tuits are focused on bigger fish such as this overall mechanism.
Hopefully you can see that it's just a bizarre warning message and a minor nuisance in the bigger scheme of things. It appears to come up if you use the FIRST phaser in a loop construct. It's got the very obvious work around which you presumably know and bbkr showed.
What is this warning about?
Many languages allow you to mix procedural and functional paradigms. Procedural code is run for its side effects. Functional code for its result. Some constructs can do both.
But what if you use a construct that's normally used with the intent of its result being used, and the compiler knows that, but it also knows it's been used in a context in which its value will be ignored?
Perls call this "useless use of ... in sink context" and generally warn the coder about it. ("sink" is an alternative/traditional term for what is often called "void" context in other language cultures.)
This error message is one of these warnings, albeit a bogus one.
And what about this is useless?
Nothing.
The related compiler warning mechanism has gotten confused.
The "Useless use of ... in sink context" part of the message is generic and hopefully self-explanatory.
But there's no way it should be saying things like "LOOP_BLOCK_1 symbol". That's internal mumbo-jumbo.
It's a warning message bug.
I didn't find any explanation in the reference, but when I type impl in IntelliJ IDEA, I get an error:
It seems that it's treated as a reserved word, but what's it for?
I tried putting many kinds of stuffs after impl but I get the error every time.
Update: It's renamed to expect after Kotlin 1.2.
It's for future multiplatform project support, and it's the pair of the header keyword which #hotkey explained in their comment here. It appeared in one of Andrey Breslav's presentations which you can find here, this specific topic starts at the 14:25 mark.
To sum it up briefly, the basic idea he presents is that you could have a common module shared between your platforms, in which there are some functions that are declared but not implemented, and are marked with the header keyword. Then, for the different platforms (JVM, JS, etc) you could have separate modules that implement these functions in platform specific ways - these actual implementations are where the impl keyword would be used.
He says that this whole system is just an internal prototype for now, so this presentation is probably all the public info we have about it. I'd also be interested in more details about this mechanism though :)
Update: as of the Kotlin 1.2 Beta, these keywords have been now replaced with expect and actual.
I'm trying to learn Smalltalk by doing, so I'm getting a grip on the syntax and style by buiding a simple "Matrix" class.
First of all, I'd be grateful if linked to a good Smalltak tutorial (although this is totally optional), preferably one that doesn't involve using the GUIs (I'd rather type my .sts than fish around the hierarchy explorer to put the methods in their place).
Then, on TDD: For this project I'm calling gst-sunit -f matrix.st -f matrix-test.st BaseMatrixTests, and there's bound to be a better way than that. Is there?
And finally, on asserts: I'm trying to write a method and put asserts within, eg.:
Matrix>>multiplyBy: anotherMatrix [
[ self isNotEmpty ] assert.
"Do Multiplication"
[ result dimensions = (self height)#(anotherMatrix width) ] assert.
]
How can I do that kind of asserts?
Edit: Questions marked explicitly.
Okay, several pieces here.
First, I agree with markusQ, although I completely sympathize: I'd rather be able to write my code in EMACS directly. Bt one of the things about Smalltalk is that it really is very unforgiving of people who don't want to do things the Smalltalk Way. In this case, the Smalltalk Way is to use the browsers.
Second, part of the reason that this is the Smalltalk Way is that Smalltalk is, in a lot of ways, not like other languages. There is really, for all practical purposes, no way to make a "separate" Smalltalk executable: all you can do is make an image of Smalltalk with some relatively small fragments of your own code added in. When you write code using an external editor, as with the syntax you show, you're literally just hand typing an import/export format that is somewhat easier to hand type than XML. But only somewhat.
The moral is, do it the Smalltalk way, with the browsers.
There are some fairly good tutorials for Smalltalk about. I usually use Squeak, so the ones I've seen are using Squeak, as here.
On TDD, you're in luck because Smalltalk was the first place to get xUnit. For Smalltalk, it's called SUnit, and there's a good tutorial here.
You're using assertions there in what appears to be basically a "design by contract" approach. There has been work done on adding design by contract to Smalltalk, as here. For simple assertions, you can add code as in this SO question.
assert: aBlock
"Throw an assertion error if aBlock does not evaluates to true."
aBlock value
ifFalse: [AssertionFailure signal: 'Assertion failed']
I hate to say it ('cause you clearly indicated you don't want to hear it), but get into the IDE. Trying to get your head around smalltalk without using the IDE is like going to Paris and eating at McDonalds. Sure, you're in Paris, but you aren't really exposing yourself to what it's all about.
The key thing about smalltalk is that it's all objects. All the way down (integers and characters are objects) and all the way up (classes, methods, the browsers, the IDE itself) are all objects. If you insist on fighting it you'll have about as much luck as someone wanting to learn how to write C by dragging and dropping things.
If you downloaded Cincom Smalltalk Non-Commercial, there are a number of online tutorials. Start here:
http://www.cincomsmalltalk.com/userblogs/cincom/blogView?content=tutorials
If you downloaded Squeak, start here:
http://wiki.squeak.org/squeak/792
And yes, you really do need to use the IDE to work effectively with Smalltalk.
On testing, load SUnit. In Cincom Smalltalk, it's a loadable component; I've covered loading (and using) it in the video tutorials linked above. I'm not entirely sure how to load it for Squeak, or whether it's part of the base there, but it's certainly available for it.
Other than a request for a tutorial, I don't see a question here. Could you clarify what it is you want to know?
A good list of resources for a beginner can be found in this question: https://stackoverflow.com/questions/481976/is-there-a-dive-into-smalltalk-book
So, about asserts, Squeak Smalltalk already brings Object>>assert:
So, I suppose you can do:
self assert: self isNotEmpty.
self assert: result dimensions equal: (self height)#(anotherMatrix width)
If you are using GNU smalltalk, this might answer how to do assertions there: Smalltalk and Assertions
Niko
Regarding asserts, please look at the other question recently posted.
Regarding TDD, yes, calling gst-sunit -f matrix.st -f matrix-test.st BaseMatrixTests is sort of the best way. Everything else just builds on that, for example these could be thee alternatives:
make all TestCase subclasses for your package inherit from a phony subclass so that you can say AllMatrixTests* on gst-sunit's command line (when you add more tests).
file in matrix.st from matrix-test.st, thus eliminating one -f option.
create a Makefile and package.xml file to create a .star file for your package, as described here. Then you can do just gst-sunit -pMatrix.
It has been suggested above to add #assert: to Object, but rather I'd add #assert to BlockClosure (or whatever [] class is in GNU Smalltalk).
assert
this value ifFalse: [AssertionFailure signal: 'Assertion failed']
and thus use as in
[ value notNil ] assert.
[ value > 0 ] assert.
[ list isEmpty not ] assert.
etcetera.
http://stores.lulu.com/store.php?fAcctID=2748699 (Also you will find the link to download the pdf)
I'd rather type my .sts than fish around the hierarchy explorer to put the methods in their place).
You say this now and I felt the same way until I invested some time into learning how to use these tools.
And I say this as a current user of Vim and former user of Emacs. I really have become quite productive using the class browser and other tools in Pharo now that I've learned the ropes.
That being said, if you really want to go your own way, GNU Smalltalk is the right choice for you.
I would like to point out at this point though that at least Pharo has a Matrix class which you can use for inspiration. Squeak should, too. Perhaps you will learn how useful the class browser is examining Matrix. ;)
Smalltalk Primer is an introduction to The Essentials of Message-Oriented Programming with Smalltalk
Theoretically, the end user should never see internal errors. But in practice, theory and practice differ. So the question is what to show the end user. Now, for the totally non-technical user, you want to show as little as possible ("click here to submit a bug report" kind of things), but for more advanced users, they will want to know if there is a work around, if it's been known for a while, etc. So you want to include some sort of info about what's wrong as well.
The classic way to do this is either an assert with a filename:line-number or a stack trace with the same. Now this is good for the developer because it points him right at the problem; however it has some significant downsides for the user, particularly that it's very cryptic (e.g. unfriendly) and code changes change the error message (Googling for the error only works for this version).
I have a program that I'm planning on writing where I want to address these issues. What I want is a way to attach a unique identity to every assert in such a way that editing the code around the assert won't alter it. (For example, if I cut/paste it to another file, I want the same information to be displayed) Any ideas?
One tack I'm thinking of is to have an enumeration for the errors, but how to make sure that they are never used in more than one place?
(Note: For this question, I'm only looking at errors that are caused by coding errors. Not things that could legitimately happen like bad input. OTOH those errors may be of some interest to the community at large.)
(Note 2: The program in question would be a command line app running on the user's system. But again, that's just my situation.)
(Note 3: the target language is D and I'm very willing to dive into meta-programming. Answers for other languages more than welcome!)
(note 4: I explicitly want to NOT use actual code locations but rather some kind of symbolic names for the errors. This is because if code is altered in practically any way, code locations change.)
Interesting question. A solution I have used several times is this: If it's a fatal error (non-fatal errors should give the user a chance to correct the input, for example), we generate a file with a lot of relevant information: The request variables, headers, internal configuration information and a full backtrace for later debugging. We store this in a file with a generated unique filename (and with the time as a prefix).
For the user, we present a page which explains that an unrecoverable error has occurred, and ask that they include the filename as a reference if they would like to report the bug. A lot easier to debug with all this information from the context of the offending request.
In PHP the debug_backtrace() function is very useful for this. I'm sure there's an equivalent for your platform.
Also remember to send relevant http headers: Probably: HTTP/1.1 500 Internal Server Error
Given a sensible format of the error report file, it's also possible to analyze the errors that users have not reported.
Write a script to grep your entire source tree for uses of these error codes, and then complain if there are duplicates. Run that script as part of your unit tests.
I know nothing about your target language, but this is an interesting question that I have given some thought to and I wanted to add my two cents.
My feeling has always been that messages for hard errors and internal errors should be as useful as possible for the developer to identify the problem & fix it quickly. Most users won't even look at this error message, but the highly sophisticated end users (tech support people perhaps) will often get a pretty good idea what the problem is and even come up with novel workarounds by looking at highly detailed error messages. The key is to make those error messages detailed without being cryptic, and this is more an art than a science.
An example from a Windows program that uses an out-of-proc COM server. If the main program tries to instantiate an object from the COM server and fails with the error message:
"WARNING: Unable to Instantiate
UtilityObject: Error 'Class Not
Registered' in 'CoCreateInstance'"
99% of users will see this and think it is written in Greek. A tech support person may quickly realize that they need ro re-register the COM server. And the developer will know exactly what went wrong.
In order to associate some contextual information with the assertion, in my C++ code I will often use a simple string with the name of the method, or something else that makes it clear where the error occured (I apologize for answering in a language you didn't ask about):
int someFunction()
{
static const std::string loc = "someFunction";
: :
if( somethingWentWrong )
{
WarningMessage(loc.c_str(), "Unable to Instantiate UtilityObject: Error 'Class Not
Registered' in 'CoCreateInstance);
}
}
...which generates:
WARNING [someFunction] : Unable to
Instantiate UtilityObject: Error
'Class Not Registered' in
'CoCreateInstance