On Tue, Dec 20, 2011 at 1:37 PM, YC wrote:
>
> By default content are encrypted either via quote-printable or base64,
> with the content-transfer-encoding set accordingly.
>
I meant encoded instead of encrypted.
Cheers,
yc
_
For
t's no
guarantee that 8bit-safe server will route only with 8bit-safe servers.
By default content are encrypted either via quote-printable or base64, with
the content-transfer-encoding set accordingly.
Cheers,
yc
_
For list-related administrative tasks:
http://lists.racket-lang.org/listinfo/dev
are what I can think of for now. Cheers.
yc
On Fri, Feb 18, 2011 at 1:21 PM, Jay McCarthy wrote:
> You may recall from the meeting over the summer that I promised a
> packaging Christmas present to Racket. I'm over a month late, but here
> it is:
>
> http://faculty.cs.byu.edu/~ja
Looks like planet is down.
On Wed, Jan 19, 2011 at 10:56 PM, Jon Rafkind wrote:
> its working for me. i just submitted a bug, too.
>
>
>
_
For list-related administrative tasks:
http://lists.racket-lang.org/listinfo/dev
On Tue, Dec 7, 2010 at 1:17 PM, Jay McCarthy wrote:
>
> I've removed the coercive contracts and replaced them with a global
> imperative any->response hook that defaults to "off" but can easily be
> turned "on" to support X-exprs or the old behavior
is, so it's harder to track down the
offending input. So having the ability to assign error to the correct
location provided by the runtime can aid people to develop their own limited
scope coercion mechanism.
Cheers,
yc
_
For list-related administrative tasks:
http://lists.racket-lang.org/listinfo/dev
want custom behavior without the work - well, they can always
wait for lib writers to come up with the hooks for them.
Hope the above sketch makes sense, the actual implementation to make it work
will obviously differ from the above depending on oth
y accessible. A compatibility library will automatically set
> current-response/c appropriately.
>
This looks great! And again thanks for taking the time to go through a
vetting process - appreciated.
Cheers,
yc
_
For list-related adminis
thon/etc enjoyed, so I constantly apply industry
expectations here, which might not be fair yet, since that might not be a
goal of the racket team, but I can hope can't I ;)
Anyhow - just my 2 cents as usual. Cheers,
yc
_
For list-related administrative tasks:
http://lists.racket-lang.org/listinfo/dev
braries, it was quite well managed.
Cheers,
yc
On Fri, Dec 3, 2010 at 10:54 PM, Jay McCarthy wrote:
> Here is my current plan:
>
> Add web-server/compat/0 directory with, e.g.,
> web-server/compat/0/http/response-structs to hold compatibility bindings to
> bridge the old http/res
such as Win32, to the point of making it super
cumbersome to use. And if they need to break the compatibility they
introduce a new version, but support both version going forward to still
keep the backward compatibility.
My 2 cents. Cheers,
yc
ed make-response-hook, and in xml
package (maybe xml/web-server.ss) can install the hook.
Such a hook will allow others to make their own extension as well to manage
their own custom response types.
My 2 cents. Cheers,
yc
_
For list-related administrative tasks:
http://lists.racket-lang.org/listinfo/dev
This is great! I sincerely believe that unifying the core & user packages
will be the key to enlarge the Racket community and get to the next level.
Looking forward to your docs! And if you need a sounding board in the mean
time I am happy to oblige.
Cheers,
yc
On Thu, Aug 12, 2010 at 2:1
e
warranted, that's great too.
Thoughts/comments/questions? Love to discuss further on this topic.
Cheers,
yc
On Wed, Jul 28, 2010 at 12:33 PM, YC wrote:
>
> On Wed, Jul 28, 2010 at 1:09 AM, Stephen De Gabrielle <
> stephen.degabrie...@acm.org> wrote:
>
>
>> I
assuming people
with higher privilege won't do such things).
Cheers,
yc
On Fri, Aug 6, 2010 at 8:22 AM, Noel Welsh wrote:
> AFAIK it is unavoidable.
>
> N.
>
> On Fri, Aug 6, 2010 at 4:08 PM, John Clements
> wrote:
> > It appears that the results of ffi-lib are persist
ow blogs do it these days.
On Wed, Jul 28, 2010 at 6:41 AM, Matthias Felleisen
wrote:
>
> On Jul 28, 2010, at 12:26 AM, YC wrote:
>
> > Other package systems separate the installation step from the import step
>
> Indeed, this is the key design decision separating us from the
the gold standard today that can be emulated.
Cheers,
yc
_
For list-related administrative tasks:
http://lists.racket-lang.org/listinfo/dev
so change collects to
become versionable in the future if you wish to re-architect the system.
Cheers,
yc
_
For list-related administrative tasks:
http://lists.racket-lang.org/listinfo/dev
ource tree access is desired, then perhaps providing a planet
source control system for module writers to opt-in for packages that become
candidates to be included in the core system can be a requirement.
This probably looks like a lot of chores at f
virtuous cycle can then be built to gain momentum to
increase the community.
I have discussed the issues in detail back in January in the thread
http://lists.racket-lang.org/users/archive/2010-January/037703.html - and
love to discuss further if others are interested.
Cheers,
yc
On Tue, Jul 27,
ons/2686019/multiple-key-presses-doing-different-events-in-c
Processing also appear to handle multiple keypress (code):
http://wiki.processing.org/index.php?title=Keep_track_of_multiple_key_presses
Here's one demo in flash with WASD - but did not show firing:
http://www.freeactionscript.
21 matches
Mail list logo
