@Libman
There is no point in what you say. You never volunteer your time to do anything.
@Araq
Now, waste your rights! I've seen a narrow minded team living in a Utopia.
Bye bye! Hope you never use the JavaScript language and libuv.
@Araq
> I'm having enough of this now. Disagreeing is not "not understanding".
One should always base one's opinion on facts rather than write hundreds of
lines of code. You said you know the JS language well. Have you ever used one
of the following tools: TypeScript or Babel, Webpack,
@Libman
> I think TypeScript is uglier than Nim, and it is objectively more verbose.
When I recommended Nim language to other people, they say they hate
indentation. Don't be conceited.
> This forum was written in Nim. Its source is more readable than anything in
> NodeJS, and its performance
@dom96 @Araq
You designed a handy language and compiler. But I think you're too concerned
about yourself (the core Nim compiler team). This thread is created for all the
enthusiasts of Nim-lang in this forum. I never thought the core team could
build these huge systems. Putting these things
@Krux02
You said your opinion, and I said mine. If you still have any intelligent
opinion, tell it.
I listed some popular excellence systems currently. Microsoft, Linux
foundation, Google Cloud, Intel and etc are all working for them. Then,
somebody thought HTML, JS, and ... are so crap, and
> Electron is further piling on top of the Web browser stack, which has always
> been and will always be crap... HTML is crap, JS is crap, IndexedDB is crap,
> etc - and anything built on top of them is crap by default. But, hey - at
> least it's a dominant open standard, so it could be worse
@Libman
I don't think so. In the future Google's ChromeOS will be a succeful OS (We
know they're working on it):
* focusing on app
* easy to install
* cheap to operate
* looks beautiful
* seamless connection to the network
Electron is not a simple adhesive, but a careful design:
>
> Hiding complexity does not remove complexity. It just gives you the illusion
> that things are simpler, when they are not.
Do you really understand the (gtk, winform) system when you develop an
application using GTK or winform? No, you don't unless you are a core member of
GTK / winform.
In
@Krux02
You should really look at [Zephry
JavaScript](https://www.zephyrproject.org/community/blog/introducing-javascript-runtime-zephyr-os)
\--- "JavaScript* is one of the most widely used programming languages today,
and in recent years has jumped from its origins on desktop web browsers to
@dom96
By the way, I think event-driven models are useful for plug-in programming. How
about adding events to asyncdispath and asynchttpserver? Such as :
proc handleError() {.async.} =
await sleepAsync(1000)
echo "handleError"
proc handleRequest(req) {.async.}
I thought:
# proc
# --> stack in
for i in 0..high(lhs) :
result[i] = lhs[i] + rhs[i]
# --> stack out
#
# --> nil
So, ...
In my opinion, "direct hardware access in Nim" means File System API, Socket
API written by C. There are equivalent wrappers in Python (written by C and
wrappered by Python).
If you want to write some "direct hardware access" low-level API, you should
comply with the specification of these C
any information?
Why not use IPC?
I really really don't want to hear about anything about GO. GO is a failure
language, OK?
You should write a session API on server with some key-value cache database
(such as redis). Then using cookie to transform session state between client
and server.
Cookie: sid=0123456abcdefg Session API
client
So beautiful!
If Salvatore Sanfilippo or somebody want to write another redis by Nim, then
what facilities does the libs offer?
Does Nim just focuse on the application layer softwares? Just another Java
without VM?
@dom96
I'd like to suggest to provide both low level pointer and high level string.
recv(socket, pointer, size) send(socket, pointer, size) specially --- just like
c socket: common, flexible, efficient.
Good job. I didn't see TCP/UDP/HTTP Servers. Are you still developing them?
@vega
I think it is different between io of httpserver and stand stream. readChar
readData ... are not useful. I think we need apis like recvOnClientError
recvOnAChunk recvOn100Continue recvOnTimeout etc.
Suggest to export the data received at each time, so that users can use this
api to customize how their datas are stored (copy to their buffer or disk
files).
It's not a bug in GC.
ref array could not allocate memory from heap. ref array is a bad represent.
Try:
type
Vector = ref object
value: array[2, float64]
Matrix = ref object
value: array[2, Vector]
IX = range[0..1]
proc newVector(): Vector =
new(result)
proc newMatrix(): Matrix =
new(result)
for ix
You just need **8192 B** (64 bit CPU) for you large files. Whenever you
actually does not need all 16GB data. Try:
import os, posix
const
BufSize = 8192
filename = "/home/king/test.txt"
var
pos = 0
size = 0
f: File
buf:
I think this will be useful when you try to write an api about database.
Natural (it mean >= 0) can represents primary key of mysql, and so on ...
@wulfklaue
Oh! ECMAScript2015, ECMAScript7 and nodejs are very popular now. I think you
just not understand JavaScript. You should have a look at:
import fs from "fs";
const stateNone = 0;
const stateRead = 1;
const stateWrite = 2;
class IO {
@OderWat
Don't mind.
不过我还是建议你用 {.async.} , 省不少事情，性能其实损失不了多少:
import asyncnet, asyncdispatch
proc recvAll(sock: AsyncSocket) {.async.} =
for i in 0 .. 50:
var ret = await recv(sock, 10)
echo("Read ", ret.len, ": ", ret.repr)
proc main() {.async.} =
var sock =
OO!
我加了个 {.gcsafe.} 可以通过了：
import asyncnet, asyncdispatch
var sock = newAsyncSocket()
var f = connect(sock, "irc.freenode.net", Port(6667))
f.callback =
proc (future: Future[void]) {.gcsafe.} =
echo("Connected in future!")
echo repr sock
这样才是正确的：
import asyncnet, asyncdispatch
var sock = newAsyncSocket()
proc onConnect(sock: AsyncSocket, host: string, port: Port) =
var ft = connect(sock, "127.0.0.1", Port(12345))
ft.callback = proc (future: Future[void]) =
echo("Connected in
Look like ECMAScript2015 (JavaScript, or TypeScript) very much ...
@bpr
> That sounds like an anti-feature to me, kind of like the anti-feature of
> Python (discussed on another thread here) that allows one to add object
> attributes at any time.
In Scala, Rust and more modern language, you can change external variable in
funcational programming.
And, this
@Krux02
> Yes, and you are ignorant to learn about them.
HAHA. I don't learn about Golang because Golang is a lousy language.
There are so many good languages better than Golang: C, Nim, Rust, Erlang,
Scala, Java, Scheme.
> Yes, live with it.
"Pure function" are not realistic. Did you know
@Krux02
> The interface construct in Go works very different from the interface
> construct in Java
I had to say I didn't see any advantage of Go interface.
> Can you tell me why your foobar in your functional solution has a function as
> argument, instead of just passing it an int directly?
@Krux02
I know interface of Java. Go is nothing magical.
Another solution:
import future
type
MyInterface = ref object of RootRef
foo: proc(this: MyInterface): int
bar: proc(this: MyInterface): int
proc foobar(this: MyInterface): int =
return this.foo(this) + this.bar(this)
type
@Krux02
OK. If you're worried about code bloated, the best way is not to use interface,
try functional programming （object-oriented programming is inflexible）:
import future
type
MyImplementationA = object
MyImplementationB = object
m_foo,m_bar:
How about:
type
MyImplementationA = object
MyImplementationB = object
m_foo,m_bar: int
proc foo(this: MyImplementationA): int =
return 17
proc bar(this: MyImplementationA): int =
return 4
proc foo(this:
39 matches
Mail list logo
