Awesome, now everything seems to work fine!

Well, I'm using SBCL version 1.1.1.0.debian. I enter in the REPL the
following two expressions:
* (defun test1 ()
    (sb-ext:exit))

* (defun test2 ()
    (sb-ext:quit))

The test1 is alright, but the test2 gives a style-warning about the
deprecation of sb-ext:quit, as follows:
; caught STYLE-WARNING:
;   SB-EXT:QUIT has been deprecated as of SBCL 1.0.56.55. Use SB-EXT:EXIT or
;   SB-THREAD:ABORT-THREAD instead.
;
;   In future SBCL versions SB-EXT:QUIT will signal a full warning at
compile-time.
In the SBCL manual it says that sb-ext:quit is an early deprecation, and
that in future versions it will be signalled as a compile-time warning.


>I think it is not a good way. There must be some stuff which didn't get to
be reloaded with this code.
>It is better to get it work like it worked before but I don't use slime
and can't fix it.
What do you mean by "get it work like it worked before"? To (exit) on the
REPL and run script/server again? Wouldn't it reload everything from the
beginning?


Another topic:
When clicking around on the app the REPL says:
WARNING:
   Cannot update the widget children of #<CLOSURE (LAMBDA #
                                                    :IN
                                                    MAKE-BLOG-WIDGET)
                                          {100C4ED47B}> because it is not a
widget.
But Robin's "Learning About Weblocks" he says that lambdas (and, by
consequence, closures) are widgets too, and the only difference is that
they are not persistent. In the warning above it looks it is being
forced/"typecasted" into a widget, giving an idea that I'm misusing lambdas
in the framework context. What is actually happening?


2013/10/6 o_z <[email protected]>

>
>
> суббота, 5 октября 2013 г., 0:33:13 UTC+3 пользователь André Miranda
> Moreira написал:
>
>> While grokking your psycho-tests login code, may I give some small
>> feedback on other stuff:
>>
>> The weblocks-app-generation-script is awesome, and just needs some small
>> fixes to work with no minor nuisances:
>>      -for some reason, when reading the 
>> lib/weblock-utils/assests-**packages.lisp,
>> it doesn't have the uiop package already loaded and complains not being
>> able to use the (uiop:getcwd) function. I just added a quickload before it.
>> Any better suggestions?
>>
> I've added uiop as dependency to weblocks-utils
>
>>      -the two functions in the script have a few repeated code that could
>> be encapsulated in a small procedure. Am I being boring?
>>
> There are some difficulties for encapsulation. After some attempts I've
> decided not to change this code.
>
>>      -the (sb-ext:exit) function was deprecated in SBCL, and it complains
>> every time that the main app file is loaded, where the function is defined.
>> Just replace it with (sb-ext:quit) on both script's functions.
>>
> I have sb-ext:quit there. Where did you find sb-ext:exit ? Also both
> sb-ext:quit and sb-ext:exit work well for me.
>
>>      -I'm still having some trouble with the require-quicklisp files. It
>> looks like it has been badly packaged:
>> ; file: path/to/app/.quicklisp-**install/require-quicklisp.lisp
>> ; in: DEFUN REQUIRE-QUICKLISP
>> ;     (AVAILABLE-VERSIONS (DIST "quicklisp"))
>> ;
>> ; caught STYLE-WARNING:
>> ;   undefined function: AVAILABLE-VERSIONS
>> Every time I start the script/server it gives me a full complaint, but
>> works anyway. How can I fix it?
>>
> I've fixed it here
> https://github.com/html/require-quicklisp/commit/31920f286cc981458ee2d2154104f5ad51687b10
>
>
>>      -I was using the linedit REPL on the terminal to interact with the
>> running app, but today I realized that I could connect to the running swank
>> server using "M-x slime-connect" on the terminal! (I loved it =] ). So, in
>> order to reload changed code into the running app, a simple function like:
>>
>> (defun reload ()
>>   (mapcar (f_ (load _))
>>                *src-files*)) ;with *src-files* defined before
>>
>> Is this a good way of reload all? Does all actually gets reloaded?
>>
> I think it is not a good way. There must be some stuff which didn't get to
> be reloaded with this code.
> It is better to get it work like it worked before but I don't use slime
> and can't fix it.
>
>>
>> Thanks for all the support!
>>
> Thanks for your feedback.
>
>> And thanks Robert Taylor for you disposal on testing. I'll surely need
>> it!
>>
>>  --
> You received this message because you are subscribed to the Google Groups
> "weblocks" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to [email protected].
> To post to this group, send email to [email protected].
> Visit this group at http://groups.google.com/group/weblocks.
> For more options, visit https://groups.google.com/groups/opt_out.
>

-- 
You received this message because you are subscribed to the Google Groups 
"weblocks" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to [email protected].
To post to this group, send email to [email protected].
Visit this group at http://groups.google.com/group/weblocks.
For more options, visit https://groups.google.com/groups/opt_out.

Reply via email to