Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

HTTP interface #433

Closed
friggeri opened this issue Feb 21, 2012 · 13 comments
Closed

HTTP interface #433

friggeri opened this issue Feb 21, 2012 · 13 comments

Comments

@friggeri
Copy link

Just wondering if some kind of network capability/interface was planned to be included in the core, or does something like this belongs to a library :

abstract Verb
abstract Get    <: Verb
abstract Post   <: Verb
abstract Put    <: Verb
abstract Delete <: Verb

type Url
    url::String
end

macro url_str(p)
    Url(p)
end

# Catch all unknown HTTP verbs
function open{T<:Verb}(url::Url, ::Type{T}) 
    error("Verb $(T) not implemented")
end

# Actual implementation for GET
function open(url::Url, ::Type{Get}) 
    # here would go the implementation
    return "Yada yada content"
end

# Assume GET if no method is specified
open(url::Url) = open(url, Get)

# Examples
print(open(url"http://www.julialang.org"))
print("\n\n")
print(open(url"http://www.julialang.org", Post))

Output :

Yada yada content

Verb Post not implemented
in error, /Users/adrien/Sources/julia/j/error.j:5
in open, http.j:17
in include, src/boot.j:192
in process_options, /Users/adrien/Sources/julia/j/client.j:163
in _start, /Users/adrien/Sources/julia/j/client.j:201
at http.j:32
@StefanKarpinski
Copy link
Member

Doesn't exist. Would be a great addition.

@ViralBShah
Copy link
Member

@friggeri
Copy link
Author

Well this was pretty much exactly what I was planning to write. I'll have to find another pet project to play with Julia !

@StefanKarpinski
Copy link
Member

You guys could collaborate :-)

@yocontra
Copy link
Contributor

Any chance we can use libuv for this feature?

@StefanKarpinski
Copy link
Member

I haven't looked into it enough, but I suspect we should embrace libuv, and if we do, we should use it wherever possible.

@JeffBezanson
Copy link
Member

I would say this doesn't need to be addressed as part of julia itself.

@ViralBShah
Copy link
Member

Not right away, but eventually, if we do want to include a package system, for example, we may need to have at least http and zlib as part of the core.

@JeffBezanson
Copy link
Member

I know these package systems are useful, no question. But I really feel the idea that every language needs its own package manager should make us think twice about how our systems are designed. What is going on here?

@ViralBShah
Copy link
Member

That's what every language has asked, and then built their own! I think our package manager should just be:

load("http://foo.com/bar.jlpkg")

Where bar.jlpkg is a directory with all the stuff that one needs. Could be made to work for binaries too, but certainly good enough for pure julia code. Of course, the local system could cache downloaded packages, etc.

-viral

On 10-Mar-2012, at 9:48 AM, JeffBezanson wrote:

I know these package systems are useful, no question. But I really feel the idea that every language needs its own package manager should make us think twice about how our systems are designed. What is going on here?


Reply to this email directly or view it on GitHub:
#433 (comment)

@StefanKarpinski
Copy link
Member

That approach is fine for doing development work but it would be horrible for deployed systems: someone upgrades the version of the code at the URL and suddenly your deployed systems all break. Awesome. This isn't hypothetical, I've experienced this using a similar system.

An interesting (and simple) approach to package management that's occurred to me is to just base the package management heavily on git. Each package is a repo — with a URL that git can fetch. If we you use the HTTPS protocol, then you even get SSL encryption and cert verification and such. Also, you have immediate access to all versions of the package: just do a git checkout of that version and then use it. It also means we don't have to implement any protocols for fetching stuff — just let git do all the work. Since GitHub exists, people can easily use it for Julia package hosting and all the tools for working on shared code are already in place.

@ViralBShah
Copy link
Member

Yes, git is a great idea. Would we be tied to using github, or could anyone serve a package from any git server exhibiting https?

-viral

On 10-Mar-2012, at 10:16 PM, Stefan Karpinski wrote:

That approach is fine for doing development work but it would be horrible for deployed systems: someone upgrades the version of the code at the URL and suddenly your deployed systems all break. Awesome. This isn't hypothetical, I've experienced this using a similar system.

An interesting (and simple) approach to package management that's occurred to me is to just base the package management heavily on git. Each package is a repo — with a URL that git can fetch. If we you use the HTTPS protocol, then you even get SSL encryption and cert verification and such. Also, you have immediate access to all versions of the package: just do a git checkout of that version and then use it. It also means we don't have to implement any protocols for fetching stuff — just let git do all the work. Since GitHub exists, people can easily use it for Julia package hosting and all the tools for working on shared code are already in place.


Reply to this email directly or view it on GitHub:
#433 (comment)

@StefanKarpinski
Copy link
Member

No, any git URL would work. GitHub would just be handy.

StefanKarpinski pushed a commit that referenced this issue Feb 8, 2018
* add Compat.Sys.BINDIR

* import Sys.BINDIR into Compat.Sys on v0.7 and add tests
cmcaine pushed a commit to cmcaine/julia that referenced this issue Nov 11, 2022
* Make lasagna hint appear

* Fix accidental double word

* Add some more hints

* Apply suggestions from code review

Co-authored-by: Sascha Mann <git@mail.saschamann.eu>
ViralBShah pushed a commit that referenced this issue Oct 16, 2023
Stdlib: SparseArrays
URL: https://github.com/JuliaSparse/SparseArrays.jl.git
Stdlib branch: main
Julia branch: master
Old commit: 4e6776a
New commit: 0f8bbda
Julia version: 1.11.0-DEV
SparseArrays version: 1.11.0
Bump invoked by: @ViralBShah
Powered by:
[BumpStdlibs.jl](https://github.com/JuliaLang/BumpStdlibs.jl)

Diff:
JuliaSparse/SparseArrays.jl@4e6776a...0f8bbda

```
$ git log --oneline 4e6776a..0f8bbda
0f8bbda Interpolate SparseVector in display test (#455)
d884072 Merge pull request #427 from JuliaSparse/jishnub/sparsevecshow
9e68b7e Merge branch 'main' into jishnub/sparsevecshow
12a1c30 remove unnecessary inequality change
4217641 don't set Documenter compat
e86b148 Adapt to Documenter v1 (#444)
8c72535 Merge branch 'main' into jishnub/sparsevecshow
8c20ba1 Test for truncation
8f925f8 Interpolate Int in expected string
c53e1f2 interpolate struct in display test
33d4bf5 Undef show with MIME text/plain
034d234 Hook into new factorization dispatch mechanisms (#437)
248d0e6 Merge branch 'main' into jishnub/sparsevecshow
713ab9b Fix documentation of `findall` behaviour (#452)
cb9b31f rowvals instead of nonzeroinds
05ac950 Add example for UMFPACK control vector (#449)
605237e Add JL_UMFPACK_PIVOT_TOLERANCE to umfpack.jl (#447)
5dac134 Use a single header wrapper for all platforms. (#446)
47e26dd Explicit types in test RHS
c123952 Interpolate vectors in show test
b309da7 Explicit types
d21fc79 Add test for showing a vector of sparsevec
3e918e4 Restore unfilled sparsevec display
b533818 Don't add SparseArrays to docs/Project.toml
4449100 Remove commented out method
728e116 ignore docs/build
99a0db2 Merge show methods
ac5c8ed Switch from internal 5-arg `searchsorted*` methods to views (#440)
ada9edd sparse vector views remain sparse (#416)
c93065c Improved the dot product between two vectors and a sparse matrix (#410)
2fae1a1 Correctly set zeros with `fill!(::SubArray)` and fix its return value (#433)
03ed9e3 Code quality cleanup (#438)
559a74e Merge branch 'main' into jishnub/sparsevecshow
8944160 fix empty show
e72223d One-line show for SparseVector
```

Co-authored-by: Dilum Aluthge <dilum@aluthge.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

5 participants