A couple of Emacs functions for scala-mode

Hello,

I have written a couple of functions for scala-mode that might be
useful for other Emacs users.

The first one is a version of scala-eval-region that sends the region
directly to the interpreter.  That is, the function does not write the
region to a temporary file, and is thus much faster.  The only
nuisance is that the interpreter outputs some spaces and a pipe for
each line of the region.

The second function, scala-eval-definition, tries to make it
unnecessary to define the region to be sent.

Please note that this is the most elisp I have written to date, so do
not hesitate to point out to me better ways to do things.

Saludos,

Victor Rodriguez.

Register in trac

Hi all,

I haven't found how to register in Trac.

And being unregistered I cannot add comments to tickets, even created by me.

S.

Re: Eclipse plugin, weird and annoying problem.

I have no idea, ctrl-z doesn't work on my system (I have a mac). Is  
this a problem with the plugin or with the JDT? I mean, does the  
problem also exist for Eclipse's Java, where we reuse all the project  
management stuff from there. In that case, you could submit a bug to  
IBM.

I'm almost there, and I'm running out of time, so I'll try to have  
something out this week or next.

Sean

On Aug 29, 2007, at 1:11 PM, toivo wrote:

>
> Eclipse plugin, weird and annoying problem.
>
> Sometimes using CTRL-Z in Scala editor destroys whole Scala project.
> Project disappears from Navigator view (also from Package view) .
>
> CTRL-Z acts like restoring state before project creation.
> Obviously this is not welcome.
> :)
>
> Fortunately project files are still on disk.
> Refresh in Navigator doesn’t bring project back.
> Import Existing Project into workspace brings project back to  
> workspace.
>
> This happed few times in past few weeks.
> I am using official Scala Plugin 2.6.3.and Eclipse 3.3

Re: Eclipse plugin, weird and annoying problem.

I have used earlier Eclipse JDT many years and never had such problem.
May be this is 3.3 bug or feature?

Anyway new plugin is much more important,
so forget this.

Thanks,
Toivo

--

-- 
View this message in context: http://www.nabble.com/Eclipse-plugin%2C-weird-and-annoying-problem.-tf4347109.html#a12447510
Sent from the Scala mailing list archive at Nabble.com.

Re: change in type of Actor.sender

David Pollak wrote:
> It changed from Actor to OutputChannel[Any]
> 
> Is there a compelling reason for this API change?

The reason is that I wanted
  reply(msg)
and
  sender ! msg
to do the same thing. Several times, people have wondered why this
wasn't the case in earlier versions.

To understand why, let's take a look at how the synchronous message send
(!?) works. Assume an actor A synchronously sends a message `msg' to
actor B:

  // inside A:
  B !? msg

Basically, what this does is send `msg' asynchronously, and then
immediately wait for a reply from B. However, it does not suffice to
wait for any message from B, since A might still have an old message
from B in its mailbox that would be mistakingly regarded as the reply.

Therefore, we have to identify messages as being sent by B *and* being
sent after B received the message that we want to sent synchronously. To
do this, A creates a private channel that is supplied as the *reply
destination* in the message send. The reply from B is then sent
automatically to this reply destination. Then, A only has to wait for a
message on this reply channel:

Repeated parameters and implicit defs

Hi,

Is there a way to declare a variable with the type of a repeated parameter?
My use case is to give a default value for the parameters of a function,
which I want to be repeated parameters:

implicit def defaultParams: ?? = ??
def myFunction(normalParam: String)(implicit def params: Param*)

I want to be eventually able to say:

myFunction {
   normalParameter
} 
and then just add:

myFunction {
   normalParameter
}(specific param1, specific param2) 

to get a more specific behavior.

How can I do that?

Eric.

--

-- 
View this message in context: http://www.nabble.com/Repeated-parameters-and-implicit-defs-tf4372567.html#a12462904
Sent from the Scala mailing list archive at Nabble.com.

Re: change in type of Actor.sender

Re: Register in trac

Hi,

There is no way to do this right now, unfortunately. Our sysadmin is 
working on it, and hopefully we'll have a way to do that soon enough. 
Until then, you can contact him (http://people.epfl.ch/fabien.salvi) and 
ask for an account. Sorry for the inconvenience.

Iulian

Stepan Koltsov wrote:
> Hi all,
> 
> I haven't found how to register in Trac.
> 
> And being unregistered I cannot add comments to tickets, even created by me.
> 
> S.
> 

Re: Annotation on inner function definitions

Julien Wetterwald <julien.wetterwald <at> epfl.ch> writes:
> Is it possible to apply a user-defined annotation on an inner function
> definition? The following code won't compile.
> 
> object test {
>    def foo {
>       <at> tailrec def bar(i: Int): Int = ...
>      ...
>    }
> }
> 
> error: illegal start of statement

I believe it should be allowed, actually.  Unless an objection shows
up (e.g. that I misread the spec), 2.6.1-RC2 will be able to parse
such an annotation.

I believe the spec already requires this annotation to be allowed.
Anyway, more generally I agree with Jon.  Even if you cannot access
such an annotation with reflection, it is still useful when processing
AST's at compile time.

In this particular case, Julien's example code has a rather suggestive
choice of name for the annotation!

-Lex

Re: Runtime annotation support

Jon Pretty <jon.pretty <at> sygneca.com> writes:
> Scala has classes StaticAnnotation and ClassfileAnnotation, but
> apparently no RuntimeAnnotation class, so I don't seem to have a way to
> write annotations which are obtainable by reflection without resorting
> to using Java.

If you inherit from ClassfileAnnotation, then the annotation should
also be visible via reflection.  Perhap the name is misleading, but
Scala has fewer categories of annotations than Java.  So you either
get a Java-visible annotation (ClassfileAnnotation), or you don't.

In general, the feeling at EPFL has been that Java's annotations are a
little baroque.  It could be we have oversimplified somewhere, though,
so by all means let us know if something seems clumsy for your
purposes.

-Lex